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ABSTRACT 


A  major  component  of  the  US  Army’s  Future  Combat  Systems  (FCS)  will  be  a 
fleet  of  eight  different  manned  ground  vehicles  (MGV).  There  are  promises  that 
‘advanced  automation’  will  take  on  many  of  the  tasks  formerly  performed  by  soldiers  in 
legacy  vehicle  systems.  However,  the  current  approach  to  automation  design  does  not 
relieve  the  soldier-operator  of  tasks;  rather,  it  changes  the  role  of  the  soldiers  and  the 
work  they  must  do,  often  in  ways  unintended  and  unanticipated.  This  thesis  proposes  a 
coherent,  top-down,  overarching  approach  to  the  design  of  a  human-automation 
interaction  model.  First,  a  qualitative  model  is  proposed  to  drive  the  functional 
architecture  and  human-automation  interface  scheme  on  the  MGV  fleet.  Second, 
proposed  model  is  applied  to  a  portion  of  the  functional  flow  of  the  common  crew  station 
on  the  MGV  fleet.  Finally,  the  proposed  model  is  demonstrated  quantitatively  via  a 
computational  task-network  modeling  program.  The  modeling  approach  offers  insights 
into  the  impacts  on  human  task-loading,  workload,  and  human  performance. 
Implications  for  other  domains  in  human  systems  integration  are  discussed.  The 
proposed  model  gives  engineers  and  scientists  a  top-down  approach  to  explicitly  define 
and  design  the  interactions  between  proposed  automation  schemes  and  the  human  crew. 
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EXECUTIVE  SUMMARY 


A  major  component  of  the  US  Army’s  Future  Combat  Systems  (FCS)  will  be  a 
fleet  of  eight  different  manned  ground  vehicles  (MGV).  There  are  promises  that 
‘advanced  automation’  will  accomplish  many  of  the  tasks  formerly  performed  by  soldiers 
in  legacy  vehicle  systems.  However,  the  current  approach  to  automation  design  does  not 
relieve  the  soldier-operator  of  tasks;  rather,  it  changes  the  role  of  the  soldiers  and  the 
work  they  must  do,  often  in  ways  unintended  and  unanticipated.  This  thesis  proposes  a 
coherent,  top-down,  overarching  approach  to  the  design  of  a  human-automation 
interaction  model. 

Given  the  available  literature  on  design  of  automation  and  the  need  at  BAE 
Systems  (one  of  the  defense  contractors  building  the  MGV  fleet),  a  qualitative  model  is 
proposed  to  drive  the  functional  architecture  and  the  human-automation  interface  scheme 
on  the  MGV  fleet.  The  model  starts  with  a  five-stage  model  of  information  processing  for 
the  human-automation  interaction  scheme  in  the  FCS  MGV  fleet  (Table  1).  It  stands 
squarely  on  the  shoulders  of  a  few  giants  in  the  field  of  human  factors  and  automation 
research  and  development  (Parasuraman,  Sheridan,  Wickens,  2000;  Kaber  &  Endsley, 
2004). 


Table  1.  Five-Stage  Model  of  Information-Processing  for  Human- Automation 
Interaction  Scheme  in  the  FCS  MGV  Fleet 


Stage 

Definition 

Information 

Acquisition 

Acquisition  and  registration  of  multiple  sources  of 
information.  Positioning  and  orienting  of  sensory  receptors, 
sensory  processing,  initial  pre-processing  of  data  prior  to 
full  processing,  and  selective  attention 
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Information 

Analysis 

Conscious  perception  and  manipulation  of  processed  and 
retrieved  information  in  working  memory.  Also  includes 
cognitive  operations  (rehearsal,  integration,  and  inference) 
occurring  prior  to  point  of  decisions. 

3 

COA  Development 

Generating  (a)  the  decisions  that  need  to  be  made,  followed 
bv  (b)  fonnulating  options  or  task  strategies  for  achieving 
goals. 
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Stage 

Definition 

Decision  Selection 

Selection  of  a  particular  option,  course  of  action  (COA),  or 
strategy  to  carry  out.  Decision(s)  are  reached  based  on  the 
Analysis  stage  (cognitive  processing),  the  COA 
Development  stage,  and  expertise  (human  or  software). 

5 

Action 

Implementation 

Consistent  with  the  decision  selection(s),  carrying  out  the 
chosen  option,  COA,  or  strategy,  whether  through  control 
actions  at  an  interface  or  other  means. 

The  proposed  human-automation  interface  model  is  shown  graphically  in  Figure 
1.  This  demonstrates  the  five  stages  of  information  processing,  as  well  as  the  possibility 
for  ten  levels  of  automation  (LOA)  within  each  of  the  five  stages.  It  retains  the 
intuitiveness  of  the  original  model  from  Parasuraman  et  al.  (2000)  while  allowing  system 
engineers  and  designers  to  explicitly  define  how  the  human  and  proposed  automation  will 
interact  so  we  might  be  able  to  understand  how  the  two  will  perform  as  part  of  the  overall 
system  in  development.  Functions  A/A'  and  Systems  B/B'  will  be  provided  as  examples 
of  how  a  human-automation  interaction  scheme  might  be  designed  conceptually. 


FCS  Manned  Ground  Vehicle  Fleet  (Common  Crew  Station) 


Acquisition  Analysis  COA  Development  Decision(s)  Action(s) 

High  High  High  High  High 


Low  Low  Low  Low  Low 


Figure  1.  Qualitative  Model  for  Design  for  Human-Automation  Interaction  in  the 
FCS  MGV  Fleet.  Note  how  the  UA  ‘Quality  of  Firsts’  are  related  to  the  proposed 
model. 

Therefore,  to  further  the  ideals  of  this  thesis,  Figure  2  graphically  presents  two 
possible  human-automation  interface  schemes  to  achieve  the  common  function  of  Local 
Defense.  The  current  scheme  (yellow  line  on  the  graph)  employs  almost  no  automation, 
only  giving  the  vehicle  commander  some  physical  aids  to  allow  arming  and  firing  of  the 
chosen  weapon  with  a  single  button  press.  The  vehicle  commander  is  totally  responsible 
for  detecting,  identifying,  and  tracking  any  local  threats.  In  the  Engagement  stage,  the 
commander  must  then  make  a  series  of  decisions  (probably  in  rapid  order)  that  starts  with 
whether  to  engage  the  target  or  not,  followed  by  selections  of  the  appropriate  weapon  and 
ammunition.  At  the  Shoot/Report  stage,  automation  design  gives  the  commander  some 
physical  help  by  only  requiring  a  simple  button  press  to  arm  the  chosen  weapon,  and  then 
another  single-button  press  to  fire  the  weapon.  Preparation  and  transmission  of  the 
digital  (i.e.,  typed  text)  situation  report  is  left  completely  with  the  commander. 
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FCS  Manned  Ground  Vehicle  Fleet  (Common  Crew  Station) 
Local  Defense  (CFM  5):  Acquire/Track/Enqaqe  Threat  (CFM  51-52) 


Proposal 


•  Characteristics 
of  target  (e.g. 
bearing,  speed, 
altitude 


•  Possible 
COAs  listed 


1.  Arm  Weapon 

2.  Fire  Weapon 

3.  Prepare/Xmit 
Digital  SITREP 


•  Symbology  of 
Target 


1.  Engage  the  Target? 

2.  Which  weapon? 

3.  Which  ammo? 


•  Status  of  ownship 
sensors 

•  Status  of  CTP/LINK 


Figure  2.  Qualitative  Model  Applied  to  the  Local  Defense  Function 


This  thesis  implemented  the  qualitative  model  applied  to  the  MGV  via  a 
computational  analysis  using  task-network  modeling  and  Monte  Carlo  simulation  from  a 
software  package  called  IMPRINT,  developed  by  the  US  Army  Research  Lab’s  Human 
Research  and  Engineering  Directorate.  Using  the  proposed  architecture  in  Figure  2,  the 
Local  Defense  function  of  the  MGV  fleet  was  modified  to  reflect  the  new  and  resulting 
human- automation  architecture  by  ‘dialing  in’  selected  levels  of  automation  for  selected 
tasks. 

Comparison  of  operator  task-loading  of  the  current  systems  vs.  the  proposed 
automation  architecture  shows  that  it  is  possible  to  reduce  operator  task-loading.  A 
primary  conclusion  of  the  thesis  is  that  by  applying  the  proposed  human-automation 
interface  model  to  other  functions  in  the  vehicles,  it  is  possible  to  make  further  reductions 
in  operator  task-loading  and  mental  workload.  This  will  also  support  attempts  to  achieve 
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the  current  ORD  requirement  for  a  vehicle  operable  by  a  2-soldier  crew.  This  work  is 
intended  to  contribute  to  the  effort  to  ensure  that  vehicle  systems  in  the  MGV  fleet  can 
accomplish  the  overall  unit  mission  and  the  FCS’  mission  as  an  acquisition  program. 
Even  if  we  eventually  conclude  that  an  additional  crewmember  is  required  on  the  various 
MGV  vehicles,  the  same  qualitative  and  quantitative  models  can  be  used  to  gain  a  clear 
understanding  of  the  human-automation  interaction  as  well  as  the  some  of  the  human 
performance  ramifications  in  terms  of  mental  workload. 

With  this  tool  in  hand,  the  exact  role  of  the  Soldier  operators  as  the  central 
component  of  the  vehicle  systems  is  clearly  understood  well  before  the  fielding  of  the 
vehicle  systems.  This  is  but  one  way  (among  several)  to  work  toward  the  ORD 
requirement  for  a  2-soldier  crew.  But,  even  if  the  2-soldier  crew  requirement  is  relaxed,  a 
coherent  plan  for  automation  will  help  to  ensure  soldier  performance  and  system 
effectiveness.  The  focus  of  the  model  is  to  ensure  that  a  reduced-crew  can  perfonn  well 
enough  (not  optimally)  to  accomplish  all  of  the  functions  and  tasks  asked  of  the  total 
vehicle  system. 

The  models  and  techniques  proposed  in  this  thesis  have  implications  beyond  just 
the  FCS  manned  vehicle.  The  general  model  and  analytical  processes,  or  similar 
approaches,  are  certainly  necessary  in  a  slew  of  complex  systems  that  lack  an 
‘automation  philosophy’  to  guide  the  design  of  a  proper  interaction  between  human  and 
automation  to  ensure  total  system  performance. 
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I.  INTRODUCTION  AND  BACKGROUND 


A.  THE  U.S.  ARMY’S  FUTURE  COMBAT  SYSTEMS  (FCS)  AND  THE 

PROMISE  OF  AUTOMATION 

Future  Combat  Systems  (FCS)  is  a  joint,  networked  system  of  systems  made  up  of 
18  individual  systems,  the  network,  and  most  importantly,  the  Soldier.  FCS  will  be 
connected  via  an  advanced  network  architecture  that  will  enable  levels  of  joint 
connectivity,  situational  awareness  and  understanding,  and  synchronized  operations 
heretofore  unachievable.  FCS  will  operate  as  a  System  of  Systems  (SoS)  that  will 
network  existing  systems,  systems  already  under  development,  and  systems  to  be 
developed  to  meet  the  requirements  of  the  Army’s  Future  Force  Unit  of  Action  (UA). 

FCS  comprises  18+1+1  systems  consisting  of  unattended  ground  sensors  (UGS); 
two  unattended  munitions,  the  Non-Line  of  Sight  -  Launch  System  (NLOS-LS)  and 
Intelligent  Munitions  System  (IMS);  four  classes  of  unmanned  aerial  vehicles  (UAVs) 
organic  to  platoon,  company,  battalion  and  Unit  of  Action  (UA)  echelons;  three  classes  of 
unmanned  ground  vehicles,  the  Armed  Robotic  Vehicle  (ARV),  Small  Unmanned 
Ground  Vehicle  (SUGV),  and  Multifunctional  Utility/Logistics  and  Equipment  Vehicle 
(MULE);  and  the  eight  manned  ground  vehicles  (18  individual  systems);  plus  the 
network  (18+1);  plus  the  Soldier  (18+1+1)  (US  Army,  2005). 

BAE  Systems  (formerly  United  Defense,  Limited  Partnership  [UDLP])  and 
General  Dynamics  Land  Systems  (GDLS)  have  been  named  the  Vehicle  Integrators  (V.I.) 
for  the  manned  ground  vehicle  (MGV)  fleet  of  FCS.  The  V.I.  team  of  BAE  Systems  and 
GDLS  are  jointly  responsible  for  design,  development,  and  production  of  the  MGV  fleet. 
The  eight  vehicles  in  the  MGV  fleet  are:  Mounted  combat  system  (MCS),  Infantry  carrier 
vehicle  (ICV),  Non-line-of-sight  cannon  (NLOS-C),  Non-line-of-sight  mortar  (NLOS- 
M),  Reconnaissance  and  surveillance  vehicle  (RSV),  Command  and  control  vehicle 
(C2V),  Medical  vehicle  (treatment  and  evacuation  variants;  MV-E  and  MV-T),  and  the 
FCS  Recovery  and  Maintenance  Vehicle  (FRMV).  Operating  under  a  cooperative 
research  and  development  agreement  (CRADA)  between  the  Naval  Postgraduate  School 
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(NPS)  and  BAE’s  offices  in  Santa  Clara,  CA  (BAE-SC),  engineers  at  BAE  have 
partnered  with  NPS  to  investigate  human  systems  integration  (HSI)  issues  related  to  the 
MGV  fleet. 

BAE  Systems  is  responsible  for  development  and  manufacture  of  several  vehicles 
in  the  MGV  fleet,  as  well  as  design  of  the  common  crew  station  (CCS)  between  all  of  the 
MGV  fleet.  The  FCS  Operational  Requirements  Documents  (ORD;  dated  31  January 
2005),  requires  that  all  FCS  Manned  Systems  must  be  operable  by  a  2-man  crew  (a  driver 
and  vehicle  commander),  with  the  rationale  being  that  the  platform  must  be  simple 
enough  for  a  2-man  crew  to  operate  effectively  (US  Army,  2005,  p.  D-7).  The  lone 
exception  is  the  MCS,  a  tank-like  vehicle  which  will  have  a  three-person  crew.  The  limit 
of  two  soldiers  is  an  intense  effort  by  the  Army  to  gain  significant  life-cycle  cost  savings 
by  eliminating  costly  manpower.  Current  annored  vehicles  in  the  Anny  fleet  typically 
have  at  least  3-4  soldiers  in  the  crew,  sometimes  more  for  certain  artillery  vehicles. 

Early  design  meetings  for  the  FCS’  Warfighter-Machine  Interface  (WMI)  have 
routinely  promised  that  ‘advanced  automation’  will  assume  many  of  the  tasks  fonnerly 
performed  by  soldiers  in  legacy  vehicle  systems.  However,  there  does  not  appear  to  be  a 
coherent  plan  to  design  the  human-automation  interface.  Instead,  various  engineers  have 
proposed  a  bottom-up  process  for  automation,  starting  with  a  detailed  task  analysis  for 
the  common  crew  station,  (personal  communications,  Jeffrey  Powers,  Dr.  Patty 
Lakinsmith,  Dr.  Douglas  Neil,  [of  BAE  Systems],  June  2005).  Then  the  V.I.  team  will 
decide  what  tasks  to  automate  based  on  technical  feasibility,  without  regard  to  the  overall 
human-automation  interface  scheme  that  would  result.  There  are  many  talented, 
dedicated  engineers  and  scientists  working  hard  to  generate  ideas  and  designs  for 
automation  on  the  MGV  fleet,  but  without  any  general  philosophy  or  overarching  design 
concept  for  automation. 

The  overall  ideas  being  proposed  for  a  human-automation  scheme  are 
inappropriate  based  on  past  experience  and  lessons  learned,  literature  reviews,  and 
multiple  transportation  accidents  (aircraft,  cars,  and  trains).  No  coherent  guide  exists  tot 
guide  decision  about  what  types  or  and  how  much  automation.  Without  a  reasoned  plan 
for  the  functional  architecture  of  automation  design,  any  automation  pieces  added  to  a 
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complex  system  are  not  likely  to  relieve  a  human  operator  of  tasks;  it  will  merely  shifts 
them  from  being  manual  tasks  to  more  supervisory  ones.  Thus,  the  human  operator  must 
become  a  ‘super-supervisor’  in  order  to  monitor  and  understand  everything  that  is  being 
automated.  The  MANPRINT/Human  Factors  chief  at  BAE  confirms  that  the  V.I.  would 
benefit  from  an  overarching  guide  to  design  the  human-automation  interface  scheme 
across  the  MGV. 

Therefore,  operating  within  a  cooperative  research  and  development  agreement 
(CRADA)  between  NPS  and  BAE-SC,  the  goal  of  this  thesis  was  to  provide  a  process  for 
developing  a  top-down,  overarching  approach  to  explicitly  define  and  design  the 
interaction  between  proposed  automation  schemes  and  the  human  crew.  It  shows  an 
approach  to  developing  a  functional  architecture  between  human  and  automation  for  the 
total  system.  While  it  was  developed  for  engineers  and  scientists  at  BAE  and  the  V.I.,  the 
process  can  be  expanded  to  a  wide  array  of  domains  (aviation,  space,  maritime,  ground 
transportation,  manufacturing,  etc.).  It  can  be  applied  to  the  FCS  MGV  fleet  to  reduce 
operator  workload  and  possibly  improve  crew  performance.  There  are  implications  for 
crew  size  in  the  total  vehicle  system. 


B.  EXAMPLES  OF  HUMAN  FAILURES  DUE  TO  POOR  AUTOMATION 

DESIGN 

There  is  a  sizable  research  base  examining  human  capabilities  (and  subsequently, 
human  error  and  failure)  involved  in  work  with  automated  systems.  New  technologies 
applied  to  the  control  of  complex  person-machine  systems  can  have  a  significant  impact 
on  operator  perfonnance  and  training  requirements.  While  reviewing  US  Army  air 
defense  command  and  control,  Hawley,  Mares,  and  Giammanco  (2005,  p.  3)  noted  that 
“the  crux  of  the  problem  of  new  technologies  applied  to  system  control  is  that  they  tend 
to  remove  human  operators  from  moment-to-moment,  on-line  control  and  relegate  them 
to  the  role  of  supervisory  controllers.  A  variety  of  research  has  indicated  that  the 
consequences  of  this  change  are  not  always  positive”  (Hawley,  Mares,  &  Giammanco, 
2005). 


3 


Norman  (1990)  detailed  the  case  of  a  fuel  leak  in  a  commercial  airliner  in  which  a 
vigilant  second  officer  detected  the  signs  of  one  possible  problem,  but  failed  to  detect 
another.  Here  is  a  quote  from  the  accident  report,  as  reported  in  Norman’s  paper  (p.  6): 

Shortly  after  level  off  at  35,000  ft...  the  second  officer  brought  to  my 
attention  that  he  was  feeding  fuel  to  all  3  engines  from  the  number  2  tank, 
but  was  showing  a  drop  in  the  number  3  tank.  I  sent  the  second  officer  to 
the  cabin  to  check  that  side  from  the  window.  While  he  was  gone,  I 
noticed  that  the  wheel  was  cocked  to  the  right  and  told  the  first  officer 
who  was  flying  the  plane  to  take  the  autopilot  off  and  check.  When  the 
autopilot  was  disengaged,  the  aircraft  showed  a  roll  tendency  confirming 
that  we  actually  had  an  out  of  balance  condition.  The  second  officer 
returned  and  said  we  were  losing  a  large  amount  of  fuel  with  a  swirl 
pattern  of  fuel  running  about  mid-wing  to  the  tip,  as  well  as  a  vapor 
pattern  covering  the  entire  portion  of  the  wing  from  mid-wing  to  the 
fuselage.  At  this  point  we  were  about  2000  lbs.  out  of  balance.... 

In  this  example,  the  second  officer  (flight  engineer)  provided  valuable  feedback 
that  something  seemed  wrong  with  the  fuel  balance.  “The  automatic  pilot  had  quietly 
and  efficiently  compensated  for  the  resulting  weight  imbalance,  and  had  the  second 
officer  not  noted  the  fuel  discrepancy,  the  situation  would  not  have  been  noted  until  much 
later,  perhaps  too  late  (1990,  p.  6).  Norman  argued  that  “it  is  essential  to  examine  the 
entire  system:  the  equipment,  the  crew,  the  social  structure,  learning  and  training, 
cooperative  activity,  and  the  overall  goals  of  the  task.  Analyses  and  remedies  that  look  at 
isolated  segments  are  apt  to  lead  to  local,  isolated  improvements,  but  they  may  also  create 
new  problems  and  difficulties  at  the  system  level”  (1990,  p.  2). 

The  aviation  realm  contains  numerous  documented  case  studies  and  research 
findings  that  detail  the  coordination  breakdown  between  flight  crews  and  automation. 
Tools  that  were  supposed  to  serve  the  human  operators  and  provided  ‘added 
functionality’  actually  present  new  challenges  in  terms  of  human  factors,  usability,  and 
training.  Woods  and  Sarter  (1998)  capture  the  user’s  perspective  on  the  current 
generation  of  automated  systems.  It  is  best  expressed  by  the  questions  they  pose  in 
describing  incidents:  “What  is  it  doing  now?  What  will  it  do  next?  How  did  I  get  into  this 
mode?  Why  did  it  do  this?  How  do  I  stop  this  machine  from  doing  this?”  (p.  5). 
Questions  like  this  point  to  automation  surprises. 
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A  landmark  paper  from  Parasuraman  and  Riley  (1997)  noted  that  designers  tend 
to  automate  everything  that  leads  to  an  economic  benefit  and  leave  the  operator  to 
manage  the  resulting  systems.  “Technical  capability  and  low  cost  are  valid  reasons  for 
automation  if  there  is  not  detrimental  impact  on  human  (and  hence  system)  performance 
in  the  resulting  system ”  (emphasis  added;  p.  232).  The  need  for  better  feedback  about 
the  automation’s  states  was  revealed  in  a  number  of  ‘controlled  flight  into  terrain’  (CFIT) 
accidents,  in  which  the  crew  selected  the  wrong  guidance  mode,  and  indications 
presented  were  similar  to  when  the  system  was  tracking  the  glide  slope  perfectly.  For 
example,  an  Airbus  320  crashed  in  Strasbourg,  France,  when  the  crew  apparently 
confused  the  vertical  speed  and  flight  path  angle  modes.  “Unfortunately,  the  ability  to 
address  human  performance  issues  systematically  in  design  and  training  has  lagged 
behind  the  application  of  automation,  and  issues  have  come  to  light  as  a  result  of 
accidents  and  incidents”  (1997,  p.  232). 


C.  AUTOMATION  IS  NOT  A  PANACEA  -  MUST  BE  GUIDED  BY  AN 

ARCHITECTURE 

‘Advanced  automation’  is  frequently  touted  as  a  solution  to  accomplish  tasks 
formerly  performed  by  Soldiers,  thereby  allowing  us  to  decrease  the  number  of  Soldiers 
manning  a  vehicle.  The  tendency  has  been  to  automate  what  is  easiest  and  leave  the  rest 
to  the  operators.  From  one  perspective,  this  dignifies  the  operators.  However,  it  may  lead 
to  a  “hodgepodge  of  partial  automation,  making  the  remaining  human  tasks  less  coherent 
and  more  complex  than  they  would  be  otherwise  be,  and  resulting  in  overall  degradation 
of  system  performance”  (Sheridan,  2002,  152). 

The  fonner  approach,  unconsciously  championed  by  many  systems,  electronics, 
and  software  engineers,  does  not  relieve  a  Soldier  of  tasks.  Rather,  it  merely  shifts 
manual  tasks  to  more  supervisory  ones.  Automation  aids  do  not  “simply  supplant  human 
but  rather  changes  it,  often  in  ways  unintended  and  unanticipated  by  the  designers  of 
automation,  and  a  result  poses  new  coordination  demands  on  the  human  operator” 
(Parasuraman,  Sheridan,  &  Wickens,  2000,  p.  286-287).  A  soldier  may  become  a 
‘super-supervisor’  trying  to  handle  the  leftover  tasks  as  well  as  monitor  that  which  has 
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been  automated.  The  engineers’  motivation  is  threefold,  albeit  noble.  First  is  to  make  the 
system  simpler  and  cheaper  to  engineer.  Second,  is  to  relieve  the  human  operator,  to 
reduce  mental  workload.  Third,  is  to  the  make  the  system  safer.  Yet  automation  can  have 
just  the  opposite  effect  in  all  three  categories  (Bainbridge,  1983  as  cited  in  Sheridan, 
2000). 

Vehicles  in  the  MGV  fleet  will  be  complex  systems  with  considerable  technology 
advances.  In  some  cases,  the  technology  might  enable  the  complete  automation  of  certain 
subsystems,  functions,  and/or  tasks.  In  many  cases,  however,  Soldiers  will  still  be  very 
much  involved  in  system  operations.  To  combat  the  increasing  complexity  and  serious 
potential  for  information  overloads,  Rouse,  Geddes,  and  Curry  (1987)  argued  that  two 
methodological  issues  must  be  addressed  (explicitly  or  implicitly)  before  beginning  the 
development  of  a  support  system  concept:  choose  a  design  methodology,  and  adopt  an 
automation  philosophy. 

Rouse  et  al.  (1987)  argue  that  any  human-machine  interface  should  involve  a  few 
common  methodological  ingredients:  an  understanding  of  the  user-system  interaction, 
human  capabilities  and  limitations  in  performing  the  general  tasks  identified,  and  the 
potential  barriers  to  using  the  interface.  In  addition,  “use  of  advanced  hardware  and 
software  technology  should  not  be  an  end  in  itself;  it  should  be  the  means  to  providing 
the  desired  functionality.  At  the  highest  levels,  this  desired  functionality  is  dictation  by 
the  automation  philosophy  underlying  the  support  system  concept”  (1987,  p.  90).  The 
automation  philosophy  is  governed  by  the  questions  of  when  and  how  to  automate,  with 
the  answers  directly  determining  the  roles  of  operators  in  systems.  “The  purpose  of 
explicitly  choosing  an  automation  philosophy  is  to  assure  that  the  implications  for 
operators’  roles  are  specific  and  acceptable  prior  to  system  design.  This  is  important 
because  the  overall  performance  of  complex  systems  depends  heavily  on  human 
performance ”  (italics  added;  1987,  p.91). 

Rouse  et  al.  caution  against  simply  automating  all  that  is  possible,  stating  that 
“this  technology-driven  approach  is  understandable,  but  is  increasingly  unacceptable  as 
the  technology  that  is  driving  automation  efforts  becomes  more  likely  to  be 
incomprehensibly  complex”  (1987,  p.  91).  They  argue  for  the  adoption  of  an  operator- 
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centered  automation  philosophy,  which  emphasizes  human  operators  in  control  and 
technology  that  provides  support,  a  concept  that  “requires  a  comprehensive  architecture 
for  an  intelligent  interface”  (1987,  p.92). 


D.  STATEMENT  OF  THE  PROBLEM 

The  FCS  MGV  fleet  lacks  an  overarching,  top-down  approach  to  its  human- 
automation  interface  scheme.  With  the  current  methodology  and  design  approach,  it  can 
be  considered  doubtful  that  perfonnance  from  a  2-soldier  crew  will  be  acceptable,  thus 
making  the  human  and  crew  performance  a  major  risk  factor  in  overall  system 
performance.  Given  the  current  ORD  requirement  for  a  2-soldier  crew,  we  must  design  a 
human-automation  interface  model  that  can  be  applied  to  the  MGV  common  crew  station 
(CCS)  to  increase  the  probability  that  a  two-soldier  crew  will  be  able  to  perform  well 
enough  to  accomplish  all  of  the  functions  and  tasks  asked  of  the  total  vehicle  system 
(hardware,  software,  and  humans)  as  part  of  the  Army’s  Unit  of  Action  (UA)  doctrine. 

While  this  thesis  focuses  on  ways  to  solve  real  technical  issues  in  the  FCS  MGV 
fleet,  the  model  and  analytical  processes  proposed,  or  similar  approaches,  certainly  are 
necessary  in  a  slew  of  complex  systems  in  multiple  domains  (aviation,  space,  maritime, 
ground  transportation,  manufacturing,  etc.).  As  a  thorough  literature  review  reveals,  there 
are  very  few  people  thinking  about  an  ‘automation  philosophy’  to  guide  the  complex 
interactions  between  humans  and  automation  to  ensure  total  system  performance.  So 
while  the  proposals  here  were  developed  for  the  FCS  MGV  fleet,  they  are  in  no  way 
limited  to  that  particular  application. 


E.  PROPOSAL 

In  response  to  the  problem  statement  detailed  above,  a  three-step  solution  is 
proposed.  The  first  step  is  to  develop  a  qualitative  model  to  drive  the  functional 
architecture  and  the  human-automation  interface  scheme  on  the  MGV  fleet.  This  is  but 
one  way  (among  several)  to  work  toward  the  ORD  requirement  for  a  2-soldier  crew.  But, 
even  if  the  2-soldier  crew  requirement  is  relaxed,  a  coherent  plan  for  automation  will  help 
to  ensure  soldier  performance  and  system  effectiveness.  The  focus  of  the  model  will  be  to 
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ensure  that  a  reduced-crew  can  perform  well  enough  (not  optimally)  to  accomplish  all  of 
the  functions  and  tasks  asked  of  the  total  vehicle  system. 

The  second  step  will  be  to  apply  the  interface  scheme  against  selected  parts  of  the 
CCS  function/task  analyses  (provided  by  BAE  human  factors  specialists  in  their  Santa 
Clara,  CA  office).  The  function/task  analysis  (FA/TA)  provides  an  overall  reference  on 
how  the  Anny  and  the  V.I.  envision  the  total  vehicle  system  to  operate.  As  such,  the 
FA/TA  is  currently  indifferent  as  to  the  allocation  of  functions  and  tasks  between  the 
hardware/software  components  of  the  system  and  the  human  crew. 

Lastly,  it  would  beneficial  to  gain  a  quantitative  understanding  how  the 
application  of  the  qualitative  model  to  a  block  of  functions  from  the  FA/TA  will  affect 
soldier  performance  in  the  common  crew  station.  One  way  to  quantify  estimated  human 
performance  in  a  system  still  in  conceptual  design  is  to  predict  human  mental  workload 
via  a  task-network  modeling  program.  In  this  case,  we  will  model  the  updated  task 
analysis  in  a  modeling  program  called  Improved  Performance  Research  and  Integration 
Tool  (IMPRINT),  provided  by  the  US  Army  Research  Laboratory’s  Human  Research  and 
Engineering  Directorate  (ARL/HRED).  IMPRINT  allows  analysts  to  quantify  operator 
mental  workload  via  prediction  of  task-loading  in  the  proposed  vehicle  system,  a  key 
aspect  of  overall  human  perfonnance  (see  ARL/HRED,  2005;  Mitchell,  2000).  The  goal 
of  this  quantitative  modeling  will  be  to  predict  whether  the  new  human-automation 
interface  scheme,  as  modeled  in  IMPRINT,  will  lower  operator  task-loading  predictions. 
If  the  mental  workload  score  predictions  are  lower  after  apply  the  new  model  of  human- 
automation  interface,  we  can  reasonably  argue  that  careful,  continued  application  of  the 
new  interface  model  may  allow  for  satisfactory  2-soldier  performance  in  the  final  system 
design. 

The  proposed  thesis  will  provide  a  top-down,  overarching  approach  that  enables 
engineers  to  explicitly  define  and  design  the  interaction  between  proposed  automation 
schemes  and  the  human  crew.  In  effect,  it  constitutes  the  design  methodology  and 
automation  philosophy,  as  espoused  by  Rouse  et  al.  (1987).  With  this  tool  in  hand,  the 
exact  role  of  the  Soldier  operators  as  the  central  component  of  the  vehicle  systems  is 

clearly  understood  well  before  the  fielding  of  the  vehicle  systems.  In  this  way,  we  can 
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take  a  step  towards  reducing  workload  peaks  and  improving  human  performance.  It  will 
also  support  attempts  to  achieve  the  current  ORD  requirement  for  a  vehicle  operable  by  a 
2-soldier  crew.  This  work  is  intended  to  contribute  to  the  effort  to  ensure  that  vehicle 
systems  in  the  MGV  fleet  can  accomplish  the  overall  unit  mission  and  the  FCS’  mission 
as  an  acquisition  program. 

F.  METHODOLOGY  OVERVIEW 

The  methodology  is  described  in  four  parts.  First,  it  was  necessary  to  conduct  a 
comprehensive  review  of  the  Army’s  doctrinal  concepts  for  the  Unit  of  Action  and  Unit 
of  Employment  (UA/UE).  FCS  is  the  materiel  solution  to  meet  the  UA/UE  concept  of 
future  warfare,  or  how  the  Anny  wants  its  soldiers  and  units  to  fight  in  the  future.  To 
understand  the  materiel  requirements,  it  is  vital  to  thoroughly  understand  the  fighting 
doctrine  that  FCS  is  being  built  to  achieve. 

The  second  major  phase  was  to  conduct  a  thorough  review  of  the  current  ORD, 
the  UA  Operational  and  Organizational  (O&O)  Plan,  the  prime  item  development 
specifications  (PIDS)  and  procurement  control  drawing  (PCDs)  for  each  of  the  vehicles 
being  developed  by  the  Army  in  conjunction  with  the  Lead  Systems  Integrator  (LSI) 
team  of  Boeing  and  SAIC.  This  family  of  doctrine,  requirements,  and  specifications 
documents  served  to  form  the  core  of  an  overall  ‘human-automation  interface’ 
requirements  listing  and  top-down  requirements  and  functional  analysis  that  was  needed 
for  the  design  phase  of  this  thesis.  Thus,  the  project  required  a  thorough  review  in 
performing  functional  and  task  analyses  (e.g.,  Kirwan  &  Ainsworth,  1992).  Human 
factors  specialists  at  BAE  have  already  developed  a  fairly  mature  FA/TA  for  the  common 
crew  station  (CCS),  and  developed  a  functional  flow  that  was  used  in  this  project. 

The  third  phase  was  to  conduct  a  thorough  literature  review  of  automation  design 
methodologies,  especially  as  they  relate  to  potentially  reducing  manning  requirements 
(Chapter  II).  Two  great  examples  of  the  military  Services  attempting  to  use  ‘advanced 
automation’  to  gain  manpower  savings  are  the  Army’s  LHX  helicopter  program  (which 
later  became  the  RAH-66  Comanche),  and  the  Navy’s  DD-X  program.  This  phase  fonned 
the  basis  for  the  qualitative  model  proposed  in  Chapter  III.  In  short,  a  5-stage  model  for 
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types  and  levels  of  automation  is  proposed,  both  in  textual  and  graphical  form.  The  5- 
stage  model  was  applied  against  a  selected  group  of  functions  from  the  CCS  FA/TA 
provided  by  engineers  at  BAE-SC.  Primary  sources  for  the  qualitative  model  include 
Parasuraman,  Sheridan,  and  Wickens  (2000),  Parasuraman  (2000),  Endsley  and  Kaber 
(1999),  Kaber  and  Endsley  (2004),  Proud,  Hart,  and  Mrozinski  (2003),  and  Billings 
(1997). 

The  fourth  phase  of  the  thesis  was  a  quantitative  task-loading  analysis  of  the  new 
human-automation  interface  in  IMPRINT.  Analysts  with  BAE-SC  and  ARL/HRED 
have  developed  a  task-network  model  in  IMPRINT  using  a  set  of  functions  common  to 
the  entire  MGV  fleet.  Using  their  model  as  a  baseline,  I  applied  the  proposed  human- 
automation  interface  scheme  to  their  selected  portions  common  function  model  (CFM)  to 
investigate  whether  predictions  of  total  mental  workload  would  decrease.  This  phase  of 
the  thesis  was  designed  to  demonstrate,  quantitatively,  how  human  task  loading  might  be 
affected  by  a  new  human-automation  interface  scheme. 

The  proposed  human-automation  interface  scheme  for  the  MGV  fleet  can 
contribute  to  multiple  HSI  and  MANPRINT  (Manpower  and  Personnel  Integration) 
domains  that  will  require  trade-off  analysis  to  resolve.  We  can  anticipate  impacts  to 
nearly  all  of  the  domains,  including  Manpower,  Personnel,  Training,  Human  Factors 
Engineering,  Soldier  Survivability,  and  System  Safety  (see  US  DoDI  5000.2,  pp.  32-33, 
and  US  Army  Regulation  602-2  for  details  of  the  HSI/MANPRINT  domains  and  their 
definitions).  The  potential  HSI  (MANPRINT)  domain  tradeoffs  will  be  discussed  in 
Chapter  VI. 

G.  DEFINITION  OF  TERMS 

A  comprehensive  list  of  acronyms  appears  on  pages  xiii-xv.  However,  there  are 
several  terms  that  must  be  defined  now  since  they  lie  at  the  heart  of  the  problem 
statement,  methodology,  and  literature  review. 

Automation  -  Device  or  system  that  accomplishes  (partially  or  fully)  a  function  that  was 
previously,  or  conceivably  could  be,  carried  out  (partially  or  fully)  by  a  human  operator 
(Parasuraman  et  al.,  2000). 
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Key  Performance  Parameter  (KPP)  -  KPPs  are  those  attributes  or  characteristics  of  a 
system  that  are  considered  critical  or  essential  to  the  development  of  an  effective  military 
capability. 

Human  Systems  Integration  (HSI)  -  comprehensive  management  and  technical  program 
that  focuses  on  the  integration  of  human  considerations  into  the  systems  acquisition 
process. 

MANPRINT  -  acronym  for  Manpower  and  Personnel  Integration,  the  US  Anny’s 
implementation  of  HSI  that  focuses  on  the  integration  of  human  considerations  into  the 
system  acquisition  process  to  enhance  soldier-system  design,  reduce  life  cycle  ownership 
costs,  and  optimize  total  system  performance. 
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II.  REVIEW  OF  THE  RELEVANT  LITERATURE 


A.  UNIT  OF  ACTION  (UA),  UNIT  OF  EMPLOYMENT  (UE),  AND  FUTURE 

COMBAT  SYSTEMS  (FCS) 

1.  UA/UE  Doctrine  and  the  ‘Quality  of  Firsts’ 

Prior  to  beginning  a  rigorous  systems  engineering  and  capabilities  needs  process 
that  will  produce  FCS,  it  is  imperative  to  thoroughly  understand  the  fighting  doctrine  that 
the  Amy  envisions  for  the  Year  2015  and  beyond.  The  Anny’s  Training  and  Doctrine 
Command  (TRADOC)  argues  that  an  increasingly  demanding  operational  environment 
(OE)  points  to  the  necessity  to  build  a  “ground  force  designed  for  rapid  deployment  and 
operations  across  the  full  spectrum  of  war”  (US  Army  TRADOC,  2003). 

To  do  this,  TRADOC  envisions  two  major  echelons  of  combat  formations:  the 
Unit  of  Action  (UA),  and  the  Unit  of  Employment  (UE).  UEs  will  be  tailorable,  higher- 
level  echelons  (what  we  now  know  as  division,  corps,  and  echelons  above  corps)  that 
integrate  and  synchronize  Army,  Joint,  and  Multinational  forces  for  full  spectrum 
operations  at  higher  operational  levels  of  war.  They  link  ground  and  joint  forces  and 
orchestrate  ground  operations  that  decide  joint  campaigns.  UEs  will  focus  on  major 
operations  and  decisive  land  campaigns  in  support  of  joint  operational  and  strategic 
objectives. 

Units  of  Action  (UA)  will  be  the  tactical  warfighting  echelons  of  the  Army’s 
Future  Force  (analogous  to  what  we  now  call  brigade  and  below).  One  or  more  UAs  may 
fight  under  the  command  and  control  of  a  UE.  The  UA  will  fight  battles;  the  UE  will 
orchestrate  multiple  engagements  to  win  battles.  The  function  of  the  UA  is  to  close  with 
and  destroy  enemy  forces  though  integrated  fire  and  maneuver,  and  tactical  assault.  UAs 
will  initiate  operations  to  gain  infonnation  superiority  and  fully  understand  the  terrain, 
weather,  enemy,  and  friendly  forces;  then  turn  that  knowledge  to  advantage  (US  Army 
TRADOC,  2002). 

There  are  two  key  concepts  in  this  brief  discussion  of  the  UA  that  are  pertinent. 
First,  formations  in  the  UA  will  be  enabled  be  a  ‘Quality  of  Firsts’ — See  First, 
Understand  First,  Act  First,  and  Finish  Decisively.  UA  capabilities  will  pennit  future 
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commanders  to  “develop  the  situation  before  making  contact,  maneuver  to  positions  of 
advantage  and,  when  ready,  initiate  decisive  action  by  destroying  enemy  systems  beyond 
the  range  of  their  weapons  to  set  the  conditions  for  decisive  assault  and  the  UA’s  ability 
to  develop  situations  out  of  contact”  (US  Army  TRADOC,  2003,  p.  1-2).  The  second  key 
concept,  already  alluded  to,  is  that  UAs  must  develop  the  situation  out  of  contact,  without 
the  need  to  first  find  and  fix  the  engaged  enemy  force  (US  Anny  TRADOC,  2002).  This 
is  a  leap-ahead  operational  paradigm,  to  be  enabled  by  new  and  emerging  technologies. 
In  the  past,  ground  maneuver  units  conducted  ‘maneuver  to  contact’  in  order  to  find  and 
fix  the  enemy,  putting  the  formation  at  significant  risk.  The  UA  concept  directs  that 
Army  forces  will  find  and  understand  the  enemy  prior  to  establishing  contact,  and  then 
act  before  the  enemy  has  a  chance  to  put  the  fonnation  in  harm’s  way. 

How  does  this  UA/UE  doctrine  pertain  to  FCS?  Simply  put  FCS  is  the  materiel 
solution  to  meet  the  UA/UE  concept  of  future  warfare,  or  how  the  Anny  wants  its 
soldiers  and  units  to  fight  in  the  future.  To  understand  the  materiel  requirements,  it  is 
vital  to  thoroughly  understand  the  fighting  doctrine  that  FCS  is  being  built  to  achieve. 
FCS  is  conceived  to  enable  the  networked  UA  to  “develop  the  situation  in  and  out  of 
contact,  set  conditions,  maneuver  to  positions  of  advantage,  and  to  close  with  and  destroy 
the  enemy  through  standoff  attack  and  combat  assault”  (US  Anny  TRADOC,  2003,  p. 
1-3).  As  described  in  Chapter  I,  the  FCS  Family  of  Systems  (FoS)  includes  a  planned 
fleet  of  manned  ground  vehicles  that  will  provide  specific  functions  in  support  of  the 
operational  concept.  “The  manned  systems  will  provide  capabilities  that  will  enable  many 
of  the  key  operational  parameters  of  the  FCS  force,  including  lethality  overmatch, 
assured  survivability  and  battle  command  on  the  move.  Essentially,  these  [manned] 
systems  contribute  to  the  synergy  that  facilitates  the  ‘quality  of  firsts’”  (US  Army 
UAMBL,  2005,  p.  D-l). 

2.  FCS  ORD 

To  understand  the  capabilities  and  requirements  that  the  US  Army  and  the  LSI  are 
trying  to  develop  with  FCS,  especially  as  it  pertains  to  various  automation  designs  in  the 
MGV  fleet,  it  is  necessary  to  thoroughly  review  the  FCS  ORD.  The  ORD  places  many 
requirements  and  needed  capabilities  on  the  MGV  fleet  and  associated  network,  far  too 
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many  to  review  in  this  thesis.  There  is  an  implicit  assumption  in  the  FCS  program  is 
expecting  the  development  and  maturation  of  a  number  of  advanced  automation 
technologies  that  can  be  integrated  in  the  overall  FoS  and  the  MGV  fleet. 

The  FCS  ORD  (see  US  Army  UAMBL,  2005,  Annex  D)  calls  for  eight  manned 
platforms  that  provide  specific  functions  in  support  of  the  operational  concept:  Mounted 
combat  system  (MCS),  Infantry  carrier  vehicle  (ICV),  Non-line-of-sight  cannon  (NLOS- 
C),  Non-line-of-sight  mortar  (NLOS-M),  Reconnaissance  and  surveillance  vehicle 
(RSV),  Command  and  control  vehicle  (C2V),  Medical  vehicle  (treatment  and  evacuation 
variants;  MV-E  and  MV-T),  and  the  FCS  Recovery  and  Maintenance  Vehicle  (FRMV). 
Figure  3  outlines  the  fleet  in  development.  The  approach  is  to  maximize  commonality  of 
these  platforms,  to  include  a  common  crew  station  (CCS)  among  all  eight  vehicles.  Also 
of  particular  importance  to  this  thesis  is  the  requirement  that  the  manned  systems  must  be 
operable  by  a  2-man  crew  (a  driver  and  vehicle  commander).  The  current  lone  exception 
is  the  MCS  variant  which  has  been  approved  for  an  increase  to  a  3-soldier  crew. 
IMPRINT  analysis  by  Mitchell,  Samms,  Henthom,  and  &  Wojciechowski  (2003)  was  the 
primary  driver  of  this  increase. 


Figure  3.  FCS  Manned  Ground  Vehicle  (MGV)  Fleet 
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To  gain  an  appreciation  for  the  breadth  and  width  of  the  requirements  placed  on 
the  MGV  fleet,  and  the  implicit  demands  for  highly  advanced  automation  that  must 
follow,  here  is  a  list  of  four  major  requirements  placed  on  the  common  crew  station: 

•  Wireless,  remote  operation  of  the  vehicle  by  a  dismounted  crewman 

•  Control  of  unmanned  systems  and  their  payloads/mission  packages 
(including  unmanned  aerial  vehicles  and  unmanned  ground  systems) 

•  Control  other  manned  platforms  through  robotic,  non-mechanical  tether 
(up  to  six  vehicles) 

•  Operable  by  one  crewmember  for  limited  periods  of  time 

Each  one  of  these  ORD  requirements  would  require  a  major  systems  engineering  and 
R&D  effort  to  achieve  the  desired  automation  design.  Undoubtedly,  the  V.I.  team  will 
assign  knowledgeable,  dependable,  multidisciplinary  teams  of  engineers  and  scientists  to 
work  on  each  requirement.  However,  it  is  safe  to  say  that  each  team  will  take  a 
significantly  different  approach  to  achieving  their  goal.  The  result  will  be  four  totally 
different  schemes  to  describe  the  resulting  interaction  between  the  human  crew  and  the 
hardware/software  automation  design.  Thus,  the  burden  will  be  placed  on  the  operators, 
as  well  as  the  training  system,  to  gain  a  full  understanding  of  how  each  of  these  modes 
will  operate. 

Beyond  the  four  examples  of  automation  modes  highlighted  above,  there  are 
dozens  of  calls  for  advanced  automation  design  on  the  MGV  fleet  throughout  the  ORD, 
both  explicit  and  implicit.  Several  examples  are:  embedded  sensor  suites,  physiological 
monitoring,  weapons  engagements,  cooperative  engagements,  chemical-biological  hazard 
detection,  signature  management,  laser  detection,  automatic  internal  lighting,  air  self 
defense  against  multiple  aerial  targets,  automated  mission  planning,  acquisition  and 
prioritization  of  multiple  targets,  monitoring  and  analysis  of  multiple  supply  needs, 
embedded  prognostics  and  diagnostics  for  maintenance,  automated  preventative 
maintenance  checks,  decision  aids  to  facilitate  maintenance  planning,  and  the  list  goes 
on.  As  an  extension  of  the  argument  in  the  previous  paragraph,  the  V.I.  team  will  employ 
dozens  of  dedicated  engineers  and  scientists  in  a  strenuous  attempt  to  meet  these 
requirements.  However,  each  person  or  team  will  likely  work  independently  of  each  other 

and  develop  their  own  overarching  architecture  for  their  piece  of  automation.  Some  may 
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attempt  to  explicitly  design  the  interaction  between  human  and  automation,  but  many  will 
not.  The  results  will  be  dozens  of  different  schemes,  explicit  or  implicit,  to  describe  the 
resulting  interaction  between  the  human  crew  and  the  hardware/software  automation 
design.  Ultimately,  it  will  be  up  to  the  FCS  training  system  and  the  Soldier  to  learn  and 
understand  the  many  different  modes  of  operation.  This  may  well  make  it  more  difficult 
for  soldiers  to  achieve  acceptable  operations  or  maintenance  performance  in  the  vehicle 
system  (though  we  have  yet  to  empirically  prove  this). 


B.  HISTORICAL  EXAMPLES  OF  AUTOMATION  VS.  MANNING  LEVELS 

The  Army’s  FCS  is  by  no  means  the  first  attempt  to  make  the  tradeoff  between 
advanced  automation  design  and  the  promise  of  reduced  manning  levels  in  extremely 
complex  systems.  There  are  four  historical  examples  reviewed  in  an  attempt  to  acquaint 
the  reader  with  other  major  technology  systems  that  were  heavily  concerned  with  the  use 
of  automation  and  the  resulting  manpower  and  human  perfonnance  concerns,  both  in  and 
out  of  the  US  DoD.  They  include  a  European  nuclear  power  plant,  a  NASA  project,  the 
US  Navy’s  DD-X,  and  ending  with  the  Army’s  LHX  program. 

1.  Nuclear  Power  Plant  -  Balancing  Automation  and  Human  Action 

In  a  case  study  of  a  specific  nuclear  power  plant  in  Europe,  Fewins,  Mitchell,  and 
Williams  (1992)  reviewed  the  assessment  of  the  plant’s  operation  to  ascertain  whether 
proposed  staffing  levels  were  adequate.  The  primary  objective  was  to  assess  “whether 
automation  provisions  with  the  design  system  would  enable  a  specified  plant  manoeuvrre 
to  be  adequately  carried  out  given  the  minimum  main  control  room  (MCR)  staffing 
complement  of  one  supervisor  and  one  desk  operator”  (Fewins  et  al.,  1992,  p.  241). 
Additional  objectives  included  identifying  requirements  for  man-machine  interface,  work 
organization,  training,  and  procedures;  HSI/MANPRINT  practitioners  will  recognize  the 
similarity  to  the  domains  of  human  factors  engineering,  manpower,  personnel,  and 
training.  They  conducted  a  hierarchical  task  analysis,  timeline  analysis,  and  workload 
assessment  to  meet  their  objectives. 

Their  analysis  strongly  indicated  that  the  workload  assessed  was  within  the 
capability  of  an  increased  staff  of  two  desk  operators  and  a  supervisor,  provided  that 
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limited  developments  to  the  automation  were  adopted.  However,  the  workload  was  much 
too  high  for  the  minimum  staffing  complement  (one  operator  and  one  supervisor)  without 
widespread  automation,  which  was  not  considered  practicable  because  of  safety 
implications  and  projected  cost.  They  recommended  an  additional  desk  operator  in  the 
staffing  complement.  Fewins,  et  al.  (1992)  also  concluded  that  limited  automation  was 
an  acceptable  option  for  reducing  operator  workload  in  selected  functions  and  tasks.  The 
use  of  their  methodology  provided  useful  recommendations  for  the  automation  of  parts  of 
the  control  process,  as  well  as  man-machine  interface  design,  and  procedures  and 
training. 

2.  Advanced  Automation  in  Spaceflight  Systems 

Despite  its  acknowledged  potential,  advanced  automation  is  rarely  used  in 
spaceflight  systems,  because  many  managers  consider  intelligent  control  systems  an 
unacceptable  risk.  A  group  of  NASA  researchers  make  the  case  for  introducing  more 
advanced  automation  into  spaceflight  systems  by  defining  systems  engineering  practices 
that  improve  reliability  and  earn  trust  (Freed,  Bonasso,  Ingham,  Kortenkamp,  Pell,  & 
Penix,  2005).  They  argue  that  automation  reduces  dependences  on  people  in  potentially 
advantageous  ways  that  can  pay  off  as  reduced  staffing  and  training  costs.  In  addition, 
onboard  automation  “can  perform  actions  that  would  otherwise  be  performed  by  the 
crew”  (Freed  et  al.,  2005),  enable  reduced  crew  size  requirements  among  other  potential 
benefits. 

Freed  et  al.’s  vision  of  advanced  automation  allows  goal-based  commanding  of 
system  activities,  in  contrast  to  timed  action-sequence  commanding  traditionally  used. 
They  also  argue  for  variable  autonomy,  or  the  ability  of  intelligent  control  software  to 
supports  changes  in  degree  of  automation.  The  goal  of  variable  autonomy  software 
architecture  is  to  allow  systems  to  operate  with  dynamically  varying  levels  of 
independence,  intelligence  and  control.  “A  human  user,  another  system,  or  the 
autonomous  user  itself  may  adjust  the  system’s  ‘level  of  autonomy’  as  required  by  the 
current  situation”  (2005,  p.  6).  A  key  conclusion  from  their  arguments  is  that  variable 
autonomy  is  necessary  for  any  application  of  autonomous  control  technology  that  needs 
to  interact  with  humans  [emphasis  added].  “Humans  who  rely  on  the  autonomous  control 
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systems  will  want  to  be  able  to  take  control  of  it  at  various  times  and  at  various  levels” 
(2005,  p.  8).  Their  concepts  on  variable  autonomy  play  a  key  part  in  the  model  of 
human- automation  interaction  proposed  in  this  thesis. 

3.  US  Navy’s  Manning  Affordability  Initiative  and  the  DD-X 

Engineers  and  scientists  with  the  US  Navy  conducted  a  program  in  1995-2000 
called  the  Manning  Affordability  Initiative  (MAI)  which  aimed  to  provide  the 
“processes,  tools,  interaction  guidelines,  and  procedures  required  to  optimize  a  combat 
systems  environment  for  the  warfighter  at  reduced  manning  levels”  (US  Navy,  2002). 
The  goal  of  the  program  was  at  least  a  50%  manpower  reduction  while  demonstrating 
operational  utility  for  all  functions  and  maintaining  or  improving  a  ship’s  operational 
performance. 

In  a  series  of  papers  advocating  an  HSI  approach  to  achieving  reduced  manning 
levels  on  future  US  Navy  ships,  there  emerged  three  main  themes  to  achieve  reduced 
manning.  First,  move  many  functions  currently  performed  by  the  ship’s  crew  off  the  ship. 
Second,  accept  increased  levels  of  risk  by  eliminating  or  consolidating  some  watch 
stations  and  reducing  some  support  and  hotel  services.  Finally,  the  point  to  the  need  to 
invest  in  emerging  technologies  that  would  reduced  the  number  of  sailors  need  onboard 
navy  ships  (Bost  &  Galdorisi,  2004;  see  also  Malone  &  Bost,  2000;  Hamburger,  Bost,  & 
McKneely,  1999). 

The  group  went  on  to  argue  for  the  selective  insertion  of  technology  (i.e., 
automation)  to  enhance  operator  performance  or  substitute  for  manpower,  with  “human 
supervision  of  automated  processes  and  human  selection  of  automation  levels.  With  the 
advent  of  ‘smarter’  systems  that  work  cooperatively  with  human  supervision,  the  role  of 
many  warfighter  shifts  from  manual  control  and  data  input  towards  strategic  thinking  and 
planning.  This  shift  in  design  focus  may  allow  one  operator  to  supervise  processes  and 
systems  that  were  previously  controlled  by  two,  three,  or  more  operators.  Thus, 
automation  must  be  planned  carefully  and  designers  must  not  necessarily  take  the  human 
out  of  the  information  loop  just  because  the  control  loop  is  removed  in  a  mission 
process.”  (Bost  &  Galdorisi,  2004,  p.  8). 
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Another  key  aspect  from  the  Navy’s  MAI  is  the  explicit  call  for  a  top-down 
function  analysis  (TDFA)  and  top-down  requirements  analysis  (TDRA).  Bost, 
McKneely,  and  Hamburger  (1998)  call  the  TDFA  a  process  that  evaluates  which  tasks 
should  be  down  manually  and  which  should  be  done  with  automation.  Typically,  the 
human  element  is  not  considered  in  the  TDFA,  leading  to  systems  that  do  not  account  for 
human  capabilities  or  limitations.  They  argue  for  tools  such  as  better  allocation  of 
functions,  function  decomposition,  and  workload  assessment,  to  name  a  few.  Similarly,  a 
TDRA  is  concerned  with  identifying,  analyzing,  and  integrating  requirements  for 
missions,  system  functions,  and  human  involvement  in  the  perfonnance  of  functions.  In 
addressing  approaches  to  reduce  system  manning,  “simply  automating  system  functions 
will  not  provide  the  warfighter  with  what  he  or  she  needs  to  monitor,  plan,  react, 
understand,  maintain  situation  awareness,  supervise,  make  decisions,  make  judgments, 
and  modify  plans  due  to  changes  in  the  tactical  situation”  (Malone  &  Bost,  2000,  p.  1). 
The  go  on  to  argue  for  the  TDRA  as  the  HSI  process  for  defining  human  requirements 
early  in  system  development.  “The  only  viable  approach  to  optimal  manning  reduction  is 
to  develop  a  system  where  human  and  machine  synergistically  and  interactively 
cooperate  to  conduct  the  mission,  and  where  the  automated  systems  supports  human 
performance....”  (2000,  p.  1). 

Before  we  close  with  our  review  of  the  Navy’s  MAI  and  reduced-manning 
programs,  it  is  important  to  draw  attention  to  the  Navy’s  DD(X)  program,  a  family  of 
Navy  ships  with  a  peculiar  and  unique  requirement:  they  must  be  manned  by  a  mere  95 
sailors,  one-third  the  usual  size  of  current  or  previous  ships  in  a  similar  mission  class.  In 
fact,  the  manning  requirement  is  a  Key  Perfonnance  Parameter  (KPP)  on  the  DD(X) 
program,  a  huge  boon  the  HSI  practitioners  involved  with  the  program  and  the  MAI. 
Since  manning  is  a  KPP  on  the  DD(X)  program,  it  will  gain  serious  attention,  engineering 
effort,  resources,  and  manpower  since  the  DD(X)  program  manager  and  the  Navy  must 
prove  that  the  DD(X)  can  perform  to  published  standards  with  a  severely  reduced  crew 
complement.  This  fact  is  important  to  note  because  the  2-soldier  crew  requirement  on  the 
Army’s  FCS  MGV  fleet  is  not  a  KPP,  and  so  far  has  not  gained  a  comparative  attention 
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and  engineering  effort  to  prove  that  its  vehicles  can  be  operated  by  only  2  soldiers  (as 
compared  to  the  traditional  4  soldiers  or  more). 

4.  The  US  Army’s  LHX  Program 

The  reduced  manning  goals  in  FCS’  MGV  fleet  are  by  no  means  the  Anny’s  first 
attempt  to  realize  manpower  savings  via  the  promise  of  advanced  automation.  Perhaps 
the  most  ambitious  helicopter  development  program  ever  undertaken  by  the  US  Army 
was  the  LHX  (for  Light  Helicopter,  Experimental),  a  system  that  eventually  became  the 
RAH-66  Comanche.  The  Army  originally  conceived  the  LHX  as  a  7500-lb  aircraft 
requiring  only  a  single  crewmember,  an  advantage  that  would  result  in  a  smaller  target 
profile,  as  well  as  realize  considerable  manpower  savings  over  the  life-cycle  of  the 
system.  Of  course,  design  for  single  crewmember  operations  would  require  considerable 
effort  and  expense  to  automate  many  systems  operations  and  functions.  Army 
helicopters  with  similar  missions  have  always  employed  two  crewmembers,  a  pilot  and 
gunner/observer  (both  rated  aviators).  In  effect,  the  Army’s  goal  was  to  introduce  such 
advanced  automation  as  to  replace  a  human  operator  and  reduce  crew  size  by  50%. 

Rigorous  analyses  by  the  Army  Research  Institute  Field  Units  at  Fort  Rucker, 
Alabama  (home  of  the  US  Army  Aviation  Center)  looked  into  human  performance  data 
while  evaluating  various  automation  options,  as  well  assessing  the  feasibility  of  operating 
the  LHX  with  a  single  crewmember.  In  a  landmark  publication,  McCracken  &  Aldrich 
(1984)  developed  an  analytical  process  for  evaluating  human  task-loading  in  the  LHX 
under  29  different  mission  scenarios,  effectively  predicting  mental  workload  via 
computational  analysis.  In  fact,  the  analytical  process  developed  by  McCracken  and 
Aldrich  is  a  precursor  of  today’s  IMPRINT  software.  The  results  of  their  study  concluded 
that  the  human  in  a  single-pilot  aircraft  would  become  overwhelmed  in  critical  situations 
(i.e.  weapons  engagements),  even  with  considerable  theorized  automation  help.  Further 
analysis  predicted  that  a  dual-crewmember  aircraft  would  experience  multiple  overload 
conditions  in  22  of  29  mission  segments,  thus  requiring  some  automation  even  with  two 
operators  in  the  cockpit. 

In  addition  to  the  analysis  at  Fort  Rucker,  the  Anny  established  the  Crew  Station 
Research  and  Development  Facility  (CSRDF)  at  NASA’s  Ames  Research  Center  at 
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Moffett  Field  in  Mountain  View,  CA  with  the  express  purpose  of  evaluating  technologies 
and  human  performance  to  determine  whether  single-pilot  operations  were  feasible  in  the 
LFIX.  Despite  considerable  efforts  at  Fort  Rucker,  the  US  Army  Aviation  Systems 
Command  in  St.  Louis,  Missouri,  and  the  CSRDF  at  NASA- Ames,  by  late  1987  the  data 
available  on  LHX  crew  performance  was  pointing  towards  the  need  for  a  dual¬ 
crewmember  setup.  Accordingly,  the  LHX  Program  Manager  went  the  US  DoD 
Acquisition  Executive  and  recommended  a  flat  decision  to  continue  development  with  a 
two-crewmember  crew  station  that  was  single-pilot  operable  (personal  communications, 
Dr.  Michael  McCauley,  July  2005;  James  Minninger,  October  2005;  Dr.  Harold  Booher, 
October  2005;  see  also  Booher,  1997). 

5.  The  US  Army’s  Previous  Crew  Reduction  Efforts  for  Ground 
Vehicles 

Before  the  thesis  closes  the  review  on  previous  examples  of  manning  vs. 
automation,  it  is  correct  to  note  that  the  Army  has  been  looking  at  reduced  manning  in  its 
ground  vehicles  for  some  time.  The  US  DoD  Human  Factors  Engineering  Technical 
Advisory  Group  (HFETAG)  has  been  looking  at  reduced  manning  for  ground  vehicles 
since  at  least  the  mid-1980s.  A  review  of  the  meeting  minutes  from  the  HFETAG 
website  (http://hfetag.dtic.mil)  shows  that  several  of  the  HFETAG  meetings  in  the  past 
twenty  years  had  presentations  on  crew  size  reduction  in  armored  vehicles. 

An  extension  of  the  1980s  HFETAG  crew  reduction  efforts  is  the  Crewman’s 
Associate  Advanced  Technology  Demonstration  (CA-ATD)  sponsored  by  the  US  Army’s 
Tank-Automative  Command  (TACOM).  Active  during  1994-2003,  the  CA-ATD 
focused  on  the  integration  of  the  crew  and  electronic  subsystems  into  current  and  future 
vehicles,  accomplished  through  the  development  of  advanced  crew  stations  which  would 
increase  crew  performance  and  reduce  crew  workload.  The  CA-ATD  program  also 
focused  on  ways  to  create  a  two-man  crew  station  while  maintaining  combat 
effectiveness.  Many  of  the  products  and  results  of  the  program  are  being  incorporated 
into  the  MGV  fleet  designs  (personal  communications,  Dr.  Patty  Lakinsmith,  July  2005; 
see  also  Karjala,  2001). 
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Lastly,  the  US  Army  nearly  fielded  a  tank-like  vehicle  with  a  three-man  crew 
(versus  the  standard  four-man)  in  the  mid-1990s.  The  M8  Armored  Guns  System  (AGS) 
was  designed  to  be  an  air-droppable,  lightweight  gun  system,  but  only  required  a  crew  of 
three  through  the  use  of  an  autoloader  (a  mostly  physical,  vice  cognitive,  function 
previously  performed  by  the  fourth  crewmember).  However,  the  program  was  terminated 
in  1996  and  abandoned,  ostensibly  due  to  budget  issues.  Incidentally,  the  AGS  is  an 
example  of  a  program  in  which  MANPRINT  considerations  were  purposely  rejected;  it  is 
not  a  coincidence  that  the  Army  canceled  the  program  (see  Booher,  2003,  p.  667; 
Federation  of  American  Scientists,  2000). 


C.  FUNCTION  ALLOCATION 

At  the  heart  of  these  previous  examples  of  automation  design  versus  possible 
manpower  reduction  has  been  the  concept  of  function  allocation  (FA).  Its  main  aim  is  to 
provide  a  rational  means  of  determining  which  systems-level  functions  should  be  carried 
out  by  humans  and  which  by  machines.  As  technology  has  progressed  over  the  past 
several  decades,  many  purchasers  of  advanced  (and  expensive)  defense  weapons  systems 
have  made  the  not-unreasonable  assertion  that  advanced  technology  can  take  over  many 
tasks  and  functions  previously  done  by  human  beings — the  most  variable,  unpredictable, 
and  expensive  part  of  the  overall  system.  “Function  allocation  tries  to  balance  attempts  to 
mechanize  or  automate  as  many  system  functions  as  possible  by  seeking  roles  and  tasks 
for  humans  that  makes  the  best  use  of  their  capabilities  while  recognizing  human 
limitations”  (Beevis,  Essens,  &  Schuffel,  1996,  p.  1).  Function  allocation  is  linked  to 
issues  of  automation  and  manpower  reduction,  as  well  as  to  questions  about  human 
responsibility  for  the  safe  and  effective  operation  of  a  system. 

In  1951,  Dr.  Paul  Fitts  edited  and  prepared  a  report  titled  Human  Engineering  for 
an  Effective  Air-Navigation  and  Traffic  Control  System.  In  this  report  he  created  two 
lists,  one  defining  what  man  is  better  able  to  accomplish,  and  another  listing  what 
machines  are  better  able  to  accomplish.  This  seminal  contribution  to  the  literature 
effectively  started  the  discipline  known  as  Function  Allocation.  By  the  late  1950s,  the 
Fitts’  List  approach  of  comparing  human  and  machine  capabilities  had  been  incorporated 
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into  a  number  of  human  engineering  guidelines  (Beevis,  Essens,  &  Schuffel,  1996).  This 
approach  grew  into  what  became  known  as  the  MABA-MABA  (Men  are  Better  At — 
Machines  are  Better  At)  lists.  This  general  approach  was  the  primary  way  to  determine 
function  allocation  within  a  system.  Table  1  lists  the  relative  capabilities  originally 
developed  by  Fitts  and  adapted  from  Sheridan  (2002)  and  Fuld  (2000)  (as  cited  in 
Wickens,  1992,  p.  429). 


Table  2. _ "Fitts'  Fist"  Showing  the  Relative  Benefits  of  Automation  and  Humans 


Humans  are  better  at 

Automation  is  better  at 

Detecting  small  amounts  of  visual,  auditory,  or 
chemical  signals  (e.g.,  evaluating  wine  or 
perfume) 

Monitoring  processes  (e.g.,  warnings) 

Detecting  a  wide  array  of  stimuli  (e.g.,  integrating 
visual,  auditory,  and  olfactory  cues  in 
cooking) 

Detecting  signals  beyond  human  capability  (e.g., 
measuring  high  temperatures,  sensing  infrared 
light  and  x-rays) 

Perceiving  patterns  and  making  generalizations 
(e.g.,  “seeing  the  big  picture”) 

Ignoring  extraneous  factors  (e.g.,  a  calculator 
doesn’t  get  nervous  during  an  exam) 

Detecting  signals  in  high  levels  of  background 
noise  (e.g.,  detecting  a  ship  on  a  cluttered 
radar  display) 

Responding  quickly  and  applying  great  force 
smoothly  and  precisely  (e.g.,  autopilots, 
automatic  torque  application) 

Improvising  and  using  flexible  procedures  (e.g., 
engineering  problem  solving,  such  as  on  the 
Apollo  13  moon  mission) 

Repeating  the  same  procedure  in  precisely  the 
same  manner  many  times  (e.g.,  robots  on 
assembly  lines) 

Storing  information  for  long  periods  and  recalling 
appropriate  parts  (e.g.,  recognizing  a  friend 
after  many  years) 

Storing  large  amounts  of  information  briefly  and 
erasing  it  completely  (e.g.,  updating  predictions 
in  a  dynamic  environment) 

Reasoning  inductively  (e.g.,  extracting  meaningful 
relationships  from  data) 

Reasoning  deductively  (e.g.,  analyzing  probable 
causes  from  fault  trees) 

Exercising  judgment  (e.g.,  choosing  between  a  job 
and  graduate  school) 

Performing  many  complex  operations  at  once  (e.g., 
data  integration  for  complex  displays,  such  as 
in  vessel  tracking) 

Despite  the  marvelous  simplicity  of  the  Fitts  Fist,  most  practitioners  and 


researchers  seem  wholly  unsatisfied  with  the  progress  of  the  FA  discipline  as  a  whole 
over  the  past  five  decades.  This  general  guideline  to  FA  was,  at  the  time,  a  proactive 
approach  to  embedding  concerns  for  human  capabilities  and  limitations  in  systems  and 
provided  a  sense  of  direction  for  the  discipline.  However,  this  historical  approach  and  its 
practice  in  the  ensuing  decades  came  to  be  an  unrealistic  and  outdated  concept,  never 
fully  developing  into  a  useful  concept.  A  1992  NATO  research  group  called  FA  the 
weakest  in  a  group  of  six  human  engineering  analysis  techniques  (Beevis,  Essens,  & 
Schuffel,  1996),  and  the  International  Journal  of  Human-Computer  Studies  dedicated  its 


24 


entire  February  2000  special  issue  to  review  the  status  of  FA.  The  workshop  drew  the 
following  conclusions  [Beevis  et  ah,  1996,  p.  xix]: 


•  Problems  with  terminology  remain,  particularly  when  human  factors 
specialists  communicate  with  those  in  other  engineering  disciplines 

•  FA  is  not  an  isolated  activity  and  must  be  incorporated  in  the  development 
process  early  enough  to  influence  design  decisions  and  to  permit  iteration 

•  No  single  technique  is  available  that  deals  with  all  of  the  issues  involved 
in  assigning  functions 

•  FA  decisions  must  be  validated  by  predictions  of  operator  workload  or 
system  performance  and  the  allocation  decisions  revised  if  necessary  in  an 
iterative  approach 

•  Little  research  activity  is  devoted  currently  to  human  behavior  in  systems 
operations  or  to  improving  human  factors  engineering  techniques 

Perhaps  the  most  telling  quote  comes  from  Sheridan,  concluding  that  FA  practitioners  are 
“obliged  to  continue  our  efforts  to  underpin  what  is  essentially  an  artful  design  synthesis 
with  a  modicum  of  science  (2000,  p.  204). 


D.  AUTOMATION  DESIGN  IS  NOT  AN  ‘ALL-OR-NONE’  CONCEPT  - 

LEVELS  OF  AUTOMATION 

1.  Levels  (Degrees)  of  Automation 

While  the  Fitts  list  gives  a  useful  starting  point  to  think  about  the  allocation  of 
functions  between  human  and  automation  (hardware  and/or  software),  many  layman  tend 
to  see  the  allocation  as  an  ‘all-or-none’,  black-or- white,  binary  affair.  The  function  or 
task  is  either  completely  manual  or  completely  automatic,  with  nothing  in  between.  We 
can  point  to  robotized  factories  as  a  popular  example  in  the  media,  with  little  mention  of 
the  associated  programming,  monitoring,  fault  detection  and  diagnosis,  and  maintenance 
functions  performed  by  humans  (Sheridan,  1992,  2002).  The  truth,  at  the  heart  of  this 
thesis,  is  that  humans  and  automation  will  work  together  as  part  of  the  FCS  Family  of 
Systems.  “The  human  and  computer  can  interact  in  an  infinite  number  of  ways,  resultant 
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in  an  infinite  spectrum  of  allocation  possibilities  from  which  to  choose”  (Sheridan,  2002, 
p.  58). 


Automation  can  vary  across  a  “continuum  of  levels,  from  the  lowest  level  of  fully 
manual  performance  to  the  highest  level  of  full  automation”  (Parasuraman,  Sheridan,  & 
Wickens,  2000,  p.  287).  Table  3  shows  the  10-point  scale  with  higher  levels 
representing  increased  autonomy  of  the  machine  over  the  human.  For  example,  at  a  low 
level  2,  several  options  are  provided  to  the  human,  but  the  system  has  no  further  say  in 
which  decision  is  chosen.  At  level  6,  the  system  automation  gives  the  human  only  a 
limited  time  to  override  before  carrying  out  the  decision.  Each  level  carries  with  it 
additional  opportunities  for  machine  error;  each  precludes  human  intervention  to  a 
greater  extent. 

Along  with  the  scale  that  he  largely  developed,  Sheridan  (1992)  anticipated  that 
for  some  tasks,  we  are  happy  to  let  the  computer  go  all  the  way,  while  for  others  we 
would  prefer  to  limit  automation  at  a  level  well  down  in  the  list.  The  tendency  has  been 
to  automate  what  is  easiest  and  to  leave  the  rest  to  the  human.  “From  one  perspective,  this 
dignifies  the  human  contribution;  from  another  it  may  lead  to  a  hodgepodge  of  partial 
automation,  making  the  remaining  human  tasks  less  coherent  and  more  complex  than 
they  need  be  and  resulting  in  an  overall  degradation  of  system  performance”  (Sheridan, 
1992,  p.  358). 

Table  3.  Levels  of  Automation  of  Decision  and  Action  Selection  (Parasuraman, 


Sheridan,  and  Wickens,  2000). 


High 

10.  The  computer  decides  everything  and  acts  autonomously,  ignoring 
the  human 

9.  Infonns  him  or  her  after  execution  if  it,  the  computer,  decides  to 

8.  Informs  him  or  her  after  execution  only  if  he  or  she  asks,  or 

7.  Executes  automatically 

6.  Allows  the  human  a  restricted  time  to  veto  before  automatic 
execution,  or 

5.  Executes  that  suggestion  if  the  human  approves,  or 

4.  Suggests  one,  and 

3.  Narrows  the  selection  down  to  a  few,  or 

2.  The  computer  offers  a  complete  set  of  action  alternatives,  or 

Low 

1 .  The  computer  offers  no  assistance;  the  human  must  do  it  all 
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2.  A  Model  for  Types  and  Levels  of  Automation 

Along  with  this  ‘Levels-of-Automation’  (LOA)  approach,  Parasuraman,  Sheridan, 
and  Wickens  (2000)  extended  the  concept  to  cover  automation  of  different  types  of 
function  in  a  human-machine  system.  The  scale  in  Table  3  refers  mainly  to  “automation 
of  decision  and  action  selection,  or  output  functions  of  a  system.  However,  automation 
may  also  be  applied  to  input  functions,  i.e.  to  functions  that  precede  decision  making  and 
action”  (2000,  p.  287).  Thus,  in  expansion  of  the  LOA  concept,  they  proposed  a  four- 
stage  view  of  human  information  processing  (Figure  4). 


Figure  4.  Simple  four-stage  model  of  human  information  processing  (Parasuraman, 
et  al.,  2000) 


By  their  own  admission,  this  four-stage  model  is  almost  certainly  a  “gross 
oversimplification  of  the  many  components  of  human  information  processing”  (2000). 
However,  their  structure  is  useful  in  practice,  and  provides  a  “simple  starting  point  with 
surprisingly  far-reaching  implications”  for  designing  the  interaction  scheme  between  a 
human  and  automation.  They  go  on  to  reason  that  the  four-stage  information  processing 
model  of  has  “its  equivalent  in  systems  functions  that  can  be  automated”  (2000).  They 
further  proposed  that  automation  can  be  applied  to  four  classes  of  function  (see  also 
Sheridan,  1998;  Billings,  1997;  Lee  &  Sandquist,  1996): 

1 .  information  acquisition 

2.  information  analysis 

3.  decision  and  action  selection 

4.  action  implementation 

Each  of  these  functions  can  be  automated  to  differing  degrees,  or  many  levels. 
The  multiple  levels  of  automation  of  decision  making  (as  shown  in  Table  2)  “can  be 
applied,  with  some  modification,  to  the  infonnation  acquisition,  information  analysis,  and 
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action  implementation  stages  as  well”  (Parasuraman,  et  al.,  2000,  p.  288).  Students  and 
fans  of  the  late  Colonel  John  Boyd,  US  Air  Force,  may  appreciate  how  the  four  broad 
functions  of  this  model  are  analogous  to  the  infamous  Observe-Orient-Decide-Act 
(OODA)  loop  commonly  used  by  defense  and  business  personnel  around  the  world  (see 
Boyd,  1996). 

The  particular  advantage  of  the  Parasuraman,  Sheridan,  and  Wickens  model  is  the 
simple  schematic  they  provide  for  model  types  and  levels  of  automation  (Figure  5).  A 
particular  system  can  involve  all  four  dimensions  at  different  levels.  Thus,  for  example,  a 
given  system  (A)  could  be  designed  to  have  moderate  to  high  acquisition  automation,  low 
analysis  automation,  low  decision  automation,  and  low  action  automation.  Another 
system  (B),  on  the  other  hand,  might  have  high  levels  of  automation  across  all  four 
functions  (2000).  Their  graphical  representation  of  a  human-automation  interface 
scheme  makes  it  particularly  easy  to  envision  the  overarching  functional  architecture  of  a 
system,  to  see  exactly  how  a  human  will  interact  with  the  designed  automation.  Like 
slider  bars  on  your  stereo  equalizer,  systems  and  human  factors  engineers  can  ‘slide  up’ 
or  ‘slide  down’  the  level  of  automation  in  each  major  function  of  a  particular,  thereby 
explicitly  specifying  how  the  human  will  interact  with  the  automation. 
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acquisition,  information  analysis,  decision  selection,  and  actin  implementation. 
Examples  of  two  systems  with  different  levels  of  automation  across  functional 
dimension  are  also  shown  (Parasuraman  et  al,  2000). 


The  model  they  outlined  provides  a  “framework  for  examining  automation  design 
issues  for  specific  systems”  (2000,  p.  289).  They  proposed  a  series  of  steps  and  an 
iterative  procedure  for  examining  which  system  functions  should  be  automated  and  to 
what  extent.  They  go  on  to  argue  that  the  human  performance  consequences  of  specific 
types  and  levels  of  automation  constitute  the  “primary  and  secondary  evaluative  criteria 
for  automation  design  using  the  model”  (2000,  p.  286).  Their  primary  evaluative  criteria 
include  mental  workload,  situation  awareness,  complacency,  and  skill  degradation. 
Secondary  evaluative  criteria  include  automation  reliability  and  costs  of  decision/action 
outcomes.  All  of  these  should  be  applied  “to  evaluate  the  feasibility  and  appropriateness 
of  particular  levels  of  automation”  (2000,  p.  289)  in  an  iterative  process. 
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In  a  closely  related  paper  published  at  the  same  time,  Parasuraman  (2000)  also 
discusses  the  types-and-levels  model  as  a  qualitative  approach  to  human-automation 
interaction  design.  However,  he  also  goes  on  to  argue  for  the  development  of 
quantitative  models  that  could  inform  the  design  of  human-automation  interaction, 
pointing  out  several  computational  and  formal  models  of  human  interaction  with 
automation.  For  example,  if  available,  such  models  “could  address  the  major  issue  in  the 
design  of  effective  human-automation  interaction,  namely  the  detennination  of  the 
specific  type  and  level  of  automation  in  a  particular  system. .  ..There  may  be  tradeoffs  in 
benefits  and  costs  involved  in  different  levels  of  automation  and  choosing  the  level  that 
maximizes  the  overall  gain  may  be  guided  by  quantitative  models”  (2000,  p.  940).  He 
concludes  that  “an  important  future  research  need  is  the  integration  of  qualitative  and 
quantitative  models”  (2000,  p.  946)  which  should  provide  for  a  more  objective  basis  for  a 
determining  effective  modes  of  human  interaction  with  automation. 

Overall,  the  model  presented  in  Parasuraman  et  al.  (2000)  and  Parasuraman 
(2000)  is  the  foundation  for  this  thesis,  as  will  be  illustrated  in  Chapter  III.  Starting  with 
their  model  for  types  and  levels  of  automation,  the  proposed  qualitative  model  blends 
ideas  from  three  other  research  teams,  each  of  which  is  discussed  below.  Beyond  that, 
the  urging  from  Parasuraman  (2000)  to  blend  in  a  quantitative  approach  gives  rise  to  the 
use  of  IMPRINT  from  ARL/HRED  as  a  way  to  predict  operator  task-loading  once  the 
proposed  qualitative  model  is  applied  to  a  system  in  development. 


E.  OTHER  LE VELS-OF - AUT OMATION  RESEARCH 

1.  Kaber  &  Endsley  Using  a  Dynamic  Control  Task 

In  addition  to  the  four-stage  model  proposed  by  Parasuraman,  Sheridan,  and 
Wickens,  there  are  two  other  major  research  teams  that  have  proposed  level-of- 
automation  taxonomies  similar  in  scope  and  intent.  The  first  major  thrust  comes  from 
Endsley  and  Kaber  (1999;  see  also  Endsley  &  Kaber,  2004;  Kaber,  Endsley,  Wright,  & 
Warren,  2002).  These  researchers  developed  a  10-level  taxonomy  applicable  to  a  wide 
range  of  psychomotor  and  cognitive  tasks,  as  well  as  numerous  work  domains,  with  four 
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generic  functions  that  can  be  allocated  to  a  human  operator  and/or  a  computer.  The 
functions  are: 


1 .  Monitoring:  taking  in  all  information  relevant  to  perceive  system  status 

2.  Generating:  formulating  options  or  task  strategies  for  achieving  goals 

3.  Selecting:  deciding  on  a  particular  option  or  strategy 

4.  Implementing:  carrying  out  the  chosen  option  through  control  actions  at  an 
interface 

In  their  work,  ten  LOAs  were  systematically  fonnulated  by  assigning  these  four  functions 
to  the  human  or  computer,  or  a  combination  of  the  two,  as  shown  in  Table  3. 


Table  4.  LOA  Taxonomy  for  human-computer  performance  in  dynamic,  multitask 


scenarios  (Endsley  &  Kaber,  1999;  Kaber  &  Endsley,  2004) 


Level  of  Automation 

Functions 

Monitoring 

Generating 

Selecting 

Implementing 

(1)  Manual  Control 

Human 

Human 

Human 

Human  | 

(2)  Action  Support 

Human/  Computer 

Human 

Human 

Human/  Computer 

(3)  Batch  Processing 

Human/  Computer 

Human 

Human 

Computer 

(4)  Shared  Control 

Human/  Computer 

Human/  Computer 

Human 

Human/  Computer 

(5)  Decision  Support 

Human/  Computer 

Human/  Computer 

Human 

Computer 

(6)  Blended  Decision  Making 

Human/  Computer 

Human/  Computer 

Human/  Computer 

Computer 

(7)  Rigid  System 

Human/ Computer 

Computer 

Human 

Computer 

(8)  Automated  Decision  Making 

Human/  Computer 

Human/  Computer 

Computer 

Computer 

(9)  Supervisory  Control 

Human/  Computer 

Computer 

Computer 

Computer 

(10)  Full  Automation 

Computer 

Computer 

Computer 

Computer 

Kaber  and  Endsley  (2004,  p.  115)  contend  that  their  LOA  taxonomy  provides 
several  advantages  over  previous/historical  hierarchies  of  LOAs.  It  provides  greater 
detail  on  ‘who’  (the  human  or  computer)  is  doing  ‘what’  at  each  LOA.”  Lurthennore,  the 
list  (Table  3)  does  not  “focus  only  on  decision  making  and  defining  authority.”  The  key 
advantage  is  that  it  allows  “careful  empirical  assessment  of  which  aspects  of  automation 
might  be  helpful  or  harmful  to  human  performance  in  conjunction  with  [the  proposed] 
system.”  They  cite  the  Parasuraman  et  al.  (2000)  model  for  LOA  design,  but  point  out 
that  their  own  model  considers  the  option  generation  (planning)  function,  instead  of  the 
information  analysis  function  in  the  Parasuraman  et  al.  model.  However,  the  other  three 
functions  in  the  Parasuraman  et  al.  model  are  identical  to  the  monitoring,  selection,  and 
implementation  features  of  the  Kaber  &  Endsley  taxonomy  (see  Table  4). 
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Table  5.  Comparison  of  Taxonomies:  Parasuraman,  Sheridan,  &  Wickens  vs. 


Kaber  &  Endsley 


Parasuraman,  Sheridan,  &  Wickens 
(2000) 

Kaber  &  Endsley  (2004);  Endsley  & 
Kaber  (1999) 

Information  Acauisition 

= 

Monitorinu 

Information  Analvsis 

— 

— 

Generating 

Decision  Selection 

— 

Selecting 

Action  Imnlementation 

= 

Tmnlementing 

In  the  three  publications  cited  from  the  team  of  Kaber  and  Endsley,  they  drew  a 
number  of  conclusions  regarding  automation  design  and  LOAs.  In  Endsley  and  Kaber 
(1999),  their  research  explored  various  LOAs  in  the  context  of  a  dynamic  control  task  as 
a  means  of  improving  overall  human/machine  perfonnance.  Results  suggest  that,  in  terms 
of  performance,  “human  operators  benefit  most  from  the  implementation  portion  of  the 
task,  buy  only  under  nonnal  operating  conditions”  (1999,  p.  462).  In  addition,  joint 
human/automation  option  generation  significantly  degraded  perfonnance  in  comparison 
to  human  or  automated  option  generation  alone. 

A  follow  on  study  from  Kaber  and  Endsley  (2004)  examined  the  effects  of  LOAs 
in  interaction  with  adaptive  automation  in  a  similar  dynamic  control  task.  Again,  results 
revealed  LOA  to  be  the  driving  factors  in  detennining  primary  task  performance.  “The 
results  are  supportive  of  intennediate  LOAs... as  approaches  to  human-centered 
automation”  (2004,  p.  113).  The  empirical  results  from  these  studies,  combined  with 
other  LOA  empirical  research  (such  as  Ruff  et  ah,  2002,  below),  give  us  some  guidelines 
for  choosing  LOAs  in  new  human-automation  systems  under  development.  The  results 
give  us  an  initial  target  for  the  proper  LOA  and  at  the  proper  function  to  gain  improved 
human  perfonnance  in  the  human-automation  interaction. 

2.  LOA  Taxonomy  from  NASA 

The  other  major  LOA  taxonomy  in  the  literature  is  a  four-stage  model  from 
Proud,  Hart,  and  Mrozinski  (2003)  out  of  the  National  Aviation  and  Space 
Administration’s  (NASA)  Johnson  Space  Center  in  Houston,  TX.  These  engineers  were 
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seeking  to  shift,  where  appropriate,  several  functions  from  humans  to  an  autonomous 
flight  management  (AFM)  system,  encapsulated  in  a  prototype  call  SMART  (Spacecraft 
Mission  Assessment  and  Re-planning  Tool).  SMART  is  a  “functionally  decomposed 
flight  management  system  with  an  appropriate  level  of  autonomy  for  each  of  its 
functions”  (2003,  p.  1),  but  Proud  et  al.  needed  a  method  to  determine  the  appropriate 
level  of  autonomy  for  each  function  within  a  system.  Starting  with  Sheridan’s  degrees  of 
automation  scale  (1992;  see  Table  2)  and  then  moving  to  the  Parasuraman  et  al.  (2000) 
four-stage  model  already  discussed,  they  realized  that  the  AFM  functions  fell  into  a 
similar  four-tier  system  using  the  terms  monitor,  analyze,  decide,  and  act. 

They  correctly  realized  one  of  the  limitations  of  the  LOA  scale  (Table  2)  in  that 
Sheridan’s  10-LOA  scale  refers  mainly  to  automation  of  decision  and  action  selection,  or 
the  output  functions  of  a  system.  Automation  may  also  be  applied  to  the  input  functions 
of  system,  i.e.  the  information  acquisition,  information  analysis,  and  even  option 
generation  functions.  They  then  integrated  aspects  of  Boyd’s  OODA  loop  (Boyd,  1996) 
to  develop  an  8-level  level  of  autonomy  scale  to  determine  how  to  assign  a  level  of 
autonomy  for  a  particular  function  (Figure  6). 


Level 

Observe 

Orient 

Decide 

The  computer  gathers, 
filters,  and  prioritizes 
data  without  displaying 
any  information  to  the 
human. 

The  computer  predicts, 
interprets,  and  integrates 
data  into  a  result  which  is 
not  displayed  to  the 
human. 

The  computer  performs 
ranking  tasks.  The 
computer  erforms  final 
ranking,  but  does  not 
display  results  to  the 
human. 

Computer  executes 
automatically  and  does 
not  allow  any  human 
interaction. 

8 

7 

The  computer  gathers, 
filters,  and  prioritizes 
data  without  displaying 
any  information  to  the 
human.  Though,  a 
program  functioning" 
flag  is  displayed. 

The  computer  analyzes, 
predicts,  interprets,  and 
integrates  data  into  a 
result  which  is  only 
displayed  to  the  human  if 
result  fits  programmed 
context  (context 
dependant  summaries). 

The  computer  performs 
ranking  tasks.  The 
computer  performs  final 
ranking  and  displays  a 
reduced  set  of  ranked 
options  without 
displaying  "why" 
decisions  were  made  to 
the  human. 

Computer  executes 
automatically  and  only 
informs  the  human  if 
required  by  context.  It 
allows  for  override 
ability  after  execution. 
Human  is  shadow  for 
contingencies. 
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Level 

Observe 

Orient 

Decide 

6 

The  computer  gathers, 
filters,  and  prioritizes 
information  displayed  to 
the  human. 

The  computer  overlays 
predictions  with  analysis 
and  interprets  the  data. 
The  human  is  shown  all 
results. 

The  computer  performs 
ranking  tasks  and 
displays  a  reduced  set  of 
ranked  options  while 
displaying  “why” 
decisions  were  made  to 
the  human. 

Computer  executes 
automatically,  informs 
the  human,  and  allows 
for  override  ability  after 
execution.  Human  is 
shadow  for 
contingencies. 

•  5 

The  computer  is 
responsible  for  gathering 
the  information  for  the 
human,  but  it  only 
displays  nonprioritized, 
filtered  information. 

The  computer  overlays 
predictions  with  analysis 
and  interprets  the  data. 
The  human  shadows  the 
interpretation  for 
contingencies. 

The  computer  performs 
ranking  tasks.  All  results, 
including  "why" 
decisions  were  made,  are 
displayed  to  the  human. 

Computer  allows  the 
human  a  context- 
dependant  restricted  time 
to  veto  before  execution. 
Human  shadows  for 
contingencies. 

4 

The  computer  is 
responsible  for  gathering 
the  information  for  the 
human  and  for 
displaying  all 
information,  but  it 
highlights  the  non¬ 
prioritized,  relevant 
information  for  the  user. 

The  computer  analyzes 
the  data  and  makes 
predictions,  though  the 
human  is  responsible  for 
interpretation  of  the  data. 

Both  human  and 
computer  perform 
ranking  tasks,  the  results 
from  the  computer  are 
considered  prime. 

Computer  allows  the 
human  a  pre¬ 
programmed  restricted 
time  to  veto  before 
execution.  Human 
shadows  for 
contingencies. 

3 

The  computer  is 
responsible  for  gathering 
and  displaying 
unfiltered,  unprioritized 
information  for  the 
human.  The  human  still 
is  the  prime  monitor  for 
all  information. 

Computer  is  the  prime 
source  of  analysis  and 
predictions,  with  human 
shadow  for 
contingencies.  The 
human  is  responsible  for 
interpretation  of  the  data. 

Both  human  and 
computer  perform 
ranking  tasks,  the  results 
from  the  human  are 
considered  prime 

Computer  executes 
decision  after  human 
approval.  Human 
shadows  for 
contingencies. 

2 

Human  is  the  prime 
source  for  gathering  and 
monitoring  all  data,  with 
computer  shadow  for 
emergencies. 

Human  is  the  prime 
source  of  analysis  and 
predictions,  with 
computer  shadow  for 
contingencies.  The 
human  is  responsible  for 
interpretation  of  the  data. 

The  human  performs  all 
ranking  tasks,  but  the 
computer  can  be  used  as 
a  tool  for  assistance. 

Human  is  the  prime 
source  of  execution,  with 
computer  shadow  for 
contingencies. 

1 

Human  is  the  only 
source  for  gathering  and 
monitoring  (defined  as 
filtering,  prioritizing  and 
understanding)  all  data. 

Human  is  responsible  for 
analyzing  all  data, 
making  predictions,  and 
interpretation  of  the  data. 

The  computer  does  not 
assist  in  or  perform 
ranking  tasks.  Human 
must  do  it  all. 

Human  alone  can 
execute  decision. 

Figure  6.  Level  of  Autonomy  Assessment  Scale  (Proud,  et  al,  2003,  p.  4) 


The  scale  from  Proud  et  al.  they  developed  in  Figure  6  also  highlights  one  of  the 
key  elements  missing  from  the  Parasuraman  et  al.  model  (2000):  the  Parasurman  et  al. 

model  lacked  useful  descriptions  of  what  the  exact  interaction  between  human  and 
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automation  is  supposed  to  be  at  each  level  of  automation  in  each  the  functions.  The  intent 
of  the  Proud  et  al.  (2003)  scale  is  “to  help  system  designers  easily  and  correctly  identify 
the  level  of  autonomy  to  design  each  function  within  their  system.  They  are  available  for 
either  identifying  the  level  of  autonomy  of  an  existing  function  or  for  proposing  an 
appropriate  level  of  autonomy  during  the  design  of  a  new  system.  The  OODA  category 
aspect  of  this  scale  is  advantageous  because:  1)  it  allows  more  specific  verbal  description 
of  the  level  of  autonomy  of  a  specific  function  than  previous  scales,  and  2)  it  allows  the 
function  types  to  be  weighted  differently  across  a  particular  level.  The  second  point  is 
important  to  understanding  the  scale  as  a  whole.  A  5  in  the  Act  column  does  not  have  the 
same  costs,  training  requirements,  or  other  assumptions  as  a  5  in  the  Orient  column” 
(Proud  et  al.,  2003,  p.  5).  The  table  developed  by  Proud  et  al.  (2003)  figures  prominently 
in  the  proposed  qualitative  model  along  with  the  Pararsuraman  et  al.  model  (2000). 

3.  LOA  Research  for  Multiple  UAVs 

Ruff,  Narayanan,  and  Draper  (2002)  reported  on  an  evaluation  that  compared 
effects  of  LOA  and  decision-aid  fidelity  on  the  number  of  UAVs  that  could  be 
successfully  controlled  by  one  operator  during  a  target  acquisition  task.  Their  LOAs 
included  manual  control,  management-by-consent,  and  management-by-exception.  The 
three  LOAs  corresponded  to  automation  levels  1,  5,  and  6  (respectively)  from  the 
Parasuraman  et  al.  (2000)  model  (see  Table  2).  Dependent  variables  included  mission 
efficiency,  percentage  correct  detection  of  incorrect  decision  aids,  workload  and  situation 
awareness  (SA)  ratings,  and  trust  in  automation  ratings.  Results  indicated  that  an 
automation  level  incorporating  management-by-consent  (Sheridan  LOA-5)  had  some 
clear  performance  advantages  over  the  more  autonomous  (management-by-exception; 
LOA-6)  and  less  autonomous  (manual  control;  LOA-1)  levels  of  automation.  LOA-5  kept 
workload  under  control  even  with  the  operator  controlling  two  or  four  UAVs,  and  SA 
scores  were  superior  for  LOA-5  across  the  number  of  UAVs  controlled. 

Ruff  et  al.  concluded  that  workload  “does  not  abate  as  human  tasks  are 
automated”  (2002,  p.  348).  Increasing  automation  to  management-by-consent  (LOA-5) 
maintains  human-in-the-loop  system  functionality,  but  it  reduces  human  responsibility  for 
functions  that  humans  do  poorly  (e.g.,  vigilant  monitoring).  Increasing  automation  to 
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management-by-exception  (LOA-6)  further  removes  the  human  from  the  decision¬ 
making  process,  lowering  SA  and  making  it  more  difficult  for  the  human  to  make 
decisions  when  he  or  she  is  finally  called  upon.  “Therefore,  the  foremost 
recommendation  that  stems  from  this  study  is  the  importance  of  an  active  role  of  the 
human  operator  in  complex  system  decision-making  processes”  (2002,  p.  348). 
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III.  QUALITATIVE  MODEL  FOR  THE  DESIGN  OF  A  HUMAN- 
AUTOMATION  INTERFACE  OF  SYSTEM  FUNCTIONS 


A.  FIVE-STAGE  MODEL  FOR  TYPES  AND  LEVELS  OF  AUTOMATION  IN 

THE  FCS  MGV  FLEET 

Given  the  available  literature  on  design  of  automation  and  the  opportunity  to 
participate  in  the  FCS  MGV  program  through  BAE-SC,  a  qualitative  model  is  proposed 
to  drive  the  functional  architecture  and  the  human-automation  interface  scheme  on  the 
MGV  fleet.  With  this  tool  in  hand,  the  exact  role  of  the  Soldier  operators  as  the  central 
component  of  the  vehicle  systems  is  clearly  understood  before  the  fielding  of  the  vehicle 
systems.  This  is  one  way  (among  several)  to  work  toward  the  ORD  requirement  for  a  2- 
soldier  crew.  But,  even  if  the  2 -soldier  crew  requirement  is  relaxed,  a  coherent  plan  for 
automation  will  help  to  ensure  soldier  performance  and  system  effectiveness.  The  focus 
of  the  model  will  be  to  ensure  that  a  reduced-crew  can  perform  well  enough  (not 
optimally)  to  accomplish  all  of  the  functions  and  tasks  asked  of  the  total  vehicle  system. 

The  model  proposed  starts  with  Table  5,  a  live-stage  model  of  information 
processing  for  the  human-automation  interaction  scheme  in  the  FCS  MGV  fleet.  It  stands 
squarely  on  the  shoulders  of  a  few  giants  in  the  field  of  human  factors  and  automation 
research  and  development.  It  starts  with  the  four-stage  model  proposed  by  Parasuraman 
et  al.  (2000)  (see  Figure  4).  In  addition,  the  LOA  taxonomy  from  Endsley  &  Kaber 
(1999)  (see  Table  3)  highlights  the  fact  that  option  generation  is  an  important  facet  of 
information-processing  scheme  for  the  MGV  fleet  and  its  soldier-operators  (see  Table  4). 

However,  the  term  ‘generation’  from  Endsley  &  Kaber  (1999)  does  not  quite 
capture  the  flavor  of  information-processing  scheme  in  these  Army  vehicles.  Instead,  we 
turn  to  Army  Field  Manual  5-0  about  the  doctrine  for  the  military  decision  making 
process  (MDMP;  see  US  Army,  2005).  Army  doctrine  uses  the  term  ‘Course  of  Action 
(COA)  Development’  to  describe  both  the  generation  and  analysis  of  strategies  to 
accomplish  a  mission,  function,  or  task.  So  the  five-stage  model  proposed  in  Table  5 
borrows  the  tenn  ‘COA  Development’  to  better  describe  the  particular  function  and  lend 
the  proper  Anny  flavor  to  this  model. 
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Table  6.  Five-Stage  Model  of  Information-Processing  for  Human-Automation 
Interaction  Scheme  in  the  FCS  MGV  Fleet 


Stage 

Definition 

Information 

Acquisition 

Acquisition  and  registration  of  multiple  sources  of 
information.  Positioning  and  orienting  of  sensory  receptors, 
sensory  processing,  initial  pre-processing  of  data  prior  to 
full  processing,  and  selective  attention 

2 

Information 

Analysis 

Conscious  perception  and  manipulation  of  processed  and 
retrieved  information  in  working  memory.  Also  includes 
cognitive  operations  (rehearsal,  integration,  and  inference) 
occurring  prior  to  point  of  decisions. 

3 

COA  Development 

Generating  (a)  the  decisions  that  need  to  be  made,  followed 
bv  (b)  fonnulating  options  or  task  strategies  for  achieving 
goals. 

Decision  Selection 

Selection  of  a  particular  option,  course  of  action  (COA),  or 
strategy  to  carry  out.  Decision(s)  are  reached  based  on  the 
Analysis  stage  (cognitive  processing),  the  COA 
Development  stage,  and  expertise  (human  or  software). 

5 

Action 

Implementation 

Consistent  with  the  decision  selection(s),  carrying  out  the 
chosen  option,  COA,  or  strategy,  whether  through  control 
actions  at  an  interface  or  other  means. 

Following  the  simple  schematic  from  the  Parasuraman  et  al  (2000)  model  shown 
in  Figure  4,  the  proposed  human-automation  interface  model  is  shown  graphically  in 
Figure  7.  This  figure  demonstrates  the  live  stages  of  information  processing,  as  well  as 
the  possibility  for  ten  LOAs  within  each  of  the  five  stages.  It  retains  the  intuitiveness  of 
the  original  model  while  allowing  system  engineers  and  designers  to  explicitly  define 
how  the  human  and  proposed  automation  will  interact.  Hopefully,  this  approach  will 
enable  better  understanding  of  how  the  two  will  perform  as  part  of  the  overall  system  in 
development.  We  will  return  to  a  discussion  of  Functions  A/A'  and  Systems  B/B' 
momentarily. 
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Figure  7.  Qualitative  Model  for  Design  for  Human-Automation  Interaction  in  the 
FCS  MGV  Fleet.  Note  how  the  UA  ‘Quality  of  Firsts’  are  related  to  the  proposed 
model. 


The  final  segment  of  the  proposed  human-automation  interface  model  borrows 
from  the  Proud  et  al.  (2003)  model.  Table  6  contains  a  description  of  the  proposed 
interaction  between  human  and  automation  at  each  function  of  the  live-stage  model 
(Table  5)  at  each  LOA.  The  descriptors  in  Table  6  are  intended  as  an  aid  to  system 
engineers  and  designers  to  understand  the  subtle  changes  in  human-automation 
interaction  with  each  change  in  LOA  at  each  function.  For  instance,  as  a  designer  thinks 
about  moving  from  LOA  3  to  LOA  6  in  the  Analysis  stage,  he  will  have  this  table  of 
descriptors  to  help  understand  the  implications  of  that  shift  in  terms  of  human-automation 
behaviors,  roles,  and  responsibilities.  The  table’s  descriptors  also  illustrate  how  human- 
automation  compares  between  two  different  stages  while  at  the  same  LOA. 
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Table  7. 


Level 


Descriptors  for  each  LOA  at  each  of  the  5 -stages  of  the  proposed  model 


Information 

Acquisition 

Information 

Analysis 

Generation 

Decision(s) 

Selection 

Action 

Implementation 

Automation  uses 

Automation 

Automation 

Automation 

Automation  carries 

internal  and  external 

predicts 

generates  the 

selects  best 

out  decision(s) 

sensors  to  gather,  filter. 

anticipated 

decision(s)  to 

choice  from  its 

autonomously 

and  prioritize  data 

future  events 

be  made  and 

own  list  of 

without  delay. 

without  displaying  any 

using 

the  COAs 

COAs.  Does 

Human  is 

information  to  the 

information 

available. 

not  display 

completely  out  of 

human  operator. 

from  objects  in 
the  environment, 
interprets  and 
integrates  data. 
Results  are  not 
displayed  to  the 
human. 

Rank  orders  the 
best  choice 
(based  on 
internal 
algorithm). 

Does  not 
display  to  the 
human 
operator. 

selection 
justification 
process  or 
choice  to 
human 
operator 

the  loop,  and  no 
intervention  is 
possible.  System 
does  not  even 
display  that  action  is 
being  implemented. 

Automation  uses 

Automation  is 

Automation 

Automation 

Automation 

internal  and  external 

an  ‘information 

generates 

selects  best 

executes  action  w/o 

sensors  to  gather,  filter. 

manager’  that 

decision(s)  to 

choice  from  its 

delay  and  only 

and  prioritize  data  w/o 

predicts, 

be  made  and 

own  list  of 

informs  the  human  if 

displaying  any 

interprets,  and 

applicable 

COAs. 

required  by  context 

information  to  the 

integrate  data 

COAs. 

Displays  the 

(or  if  automation 

human.  Only  displays 

into  a  result 

Displays  best 

selection 

decides  to).  No 

“program  functioning” 

which  is  only 

option  to 

process  only  if 

override  or 

flag  to  confirm  system 

displayed  to  the 

human  operator 

required  by 

intervention  is 

status;  human  monitors 
system  status  via  flag, 
and  takes  over  sensors 
if  necessary 
(essentially  moving 
down  one  level). 

human  if  result 
fit  programmed 
context  (context- 
dependent 
summary) 

only  if  asked 
for  it. 

context. 

possible(?) 

Automation  uses 

Automation  is 

Automation 

Automation 

Automation 

internal  and  external 

an  ‘information 

generates 

displays  best 

executes  w/o  delay 

sensors  to  gather,  filter, 

manager’  that 

decision(s)  to 

choice  from  its 

and  only  informs 

and  prioritize  data  w/o 

predicts, 

be  made  and 

own  list  of 

human  of  action  if 

displaying  any 

interprets,  and 

applicable 

COAs. 

asked  for  it. 

information  to  the 

integrates  data 

COAs.  Rank 

Displays 

Override  by  human 

human.  On  request, 

into  a  result 

orders  COAs 

selection 

is  possible  after 

displays  status  of  sub- 

(context- 

for  each 

process  and 

execution  starts; 

systems  (sensors, 

dependent 

decision. 

result  if  asked 

human  monitors  for 

comm,  links,  weapons, 
links,  etc)  for  human  to 
monitor. 

summary)  which 
is  only  displayed 
if  asked  for  by 
the  human. 
Information 
integration 
augments  human 
operator 
perception  and 
cognition. 

Displays  list 
(up  to  5)  only  if 
human  asks  for 
it. 

by  human 
operator. 

contingencies. 

8 
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Level 

Information 

Acquisition 

Information 

Analysis 

Generation 

Decision(s) 

Selection 

Action 

Implementation 

Automation  uses 

Automation 

Automation 

Automation 

Automation 

internal  and  external 

overlays 

generates 

displays  top 

executes  w/o  delay, 

sensors  to  gather,  filter, 

predictions  with 

decisions  to  be 

recommended 

informs  the  human 

and  prioritize  data. 

analysis  and 

made  and 

COA  to  human 

explicitly,  and 

Displays  filter  and 

interprets  the 

COAs.  Rank 

for  yes/no 

allows  for  override 

prioritized  information 
to  human.  Also 

data  (simple 
summary,  not 

order  COAs 
(by  embedded 

decision. 

after  execution. 
Human  monitors  for 

7 

displays  sub-systems 
statuses  for  human  to 
monitor.  Automation 
has  primary  control 
over  sensors  to  scan 
and  observe;  human 
can  take  over  sensor 
placement. 

context- 
dependent).  The 
human  is  shown 
all  of  the  results. 

algorithm  or 
criteria),  and 
displays  the 
best  option  to 
the  operator. 

contingencies. 

Automation 

Automation 

Automation 

Automation 

Automation  delays 

responsible  to  gather 

overlays 

generates 

displays  up  to 

execution  by  a 

data  via  sensors  and 

predictions  with 

decision(s)  to 

5  COAs  in 

context-dependent 

links.  Displays  only 

analysis  and 

be  made  and 

rank  order, 

amount  of  time  that 

highlighted,  prioritized. 

interprets  the 

COAs  and 

from  which  the 

allows  the  human 

relevant  information. 

data.  Human 

displays  in 

human  must 

operator  to  veto  the 

6 

along  with  sub-systems 
statuses.  Automation 
has  primary  control 
over  sensors  to  scan 
and  observe;  human 
can  take  over  sensor 
placement. 

monitors  the 
interpretation  for 
contingencies. 

recommended 
rank  order  (up 
to  5  COAs)  to 
human 
operator. 
Operator  may 
generate 
additional 
decision(s)  and 
COAs,  but  not 
for  input  to 
computer. 

choose. 

action  before  it  is 
carried  out.  Human 
monitors  for 
contingencies. 

Automation 

Automation 

Automation 

Automation 

Automation  delays 

responsible  to  gather 

analyzes  the  data 

generates 

displays  up  to 

execution  by  a  pre- 

data  via  sensors  and 

and  makes 

decision(s)  to 

5  COAs  in 

programmed  (fixed) 

links.  Displays  all  data 

predictions. 

be  made  and 

rank  order. 

amount  of  time  that 

to  human  operator,  but 

Human 

COAs. 

Human 

allows  the  human 

highlights  prioritized, 

completes 

Displays  in 

chooses  from 

operator  to  veto  the 

relevant  information. 

interpretation 

recommended 

this  list,  or 

action  before  it  is 

Displays  sub-systems 

and  integration 

rank  order  (up 

from  own  list. 

carried  out.  Human 

5 

statuses.  Automation 
has  primary  control 
over  sensors  to  scan 
and  observe;  human 
can  take  over  sensor 
placement. 

into  information. 

to  5)  to  human 
operator. 

Human  may 
generate 
additional 
decision(s)  and 
COA(s)  for 
input  to 
computer. 

monitors  for 
contingencies. 
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Level 


Information 

Information 

Generation 

Decision(s) 

Action 

Acquisition 

Analysis 

Selection 

Implementation 

Automation 

Automation  is 

Automation 

Automation 

Automation 

responsible  to  gather 

the  prime  source 

generates 

displays  full 

executes  after 

data  via  sensors  and 

for  analysis  and 

decision(s)  to 

list  of  COAs  in 

human  operator 

links.  Displays  all  data 

prediction. 

be  made  and 

recommended 

explicitly  approves. 

to  human  operator,  but 

Human 

COAs. 

rank  order. 

Human  monitors  for 

highlights  non- 

monitors,  and  is 

Displays  full 

Human  can 

contingencies. 

prioritized,  relevant 

responsible  for 

list  in 

choose  from 

information.  Displays 

prediction  and 

recommended 

this  list,  or 

sub-systems  statuses. 

integration  of 

rank  order  to 

from  own  list 

Automation  has 

data  into 

human 

of  COAs. 

primary  control  over 

information. 

operator. 

sensors  to  scan  and 

Operator  may 

observe;  human  can 

generate 

take  over  sensor 

additional 

placement. 

decision(s)  and 
COA(s)  for 
input  to 
computer  (if 
needed). 

Automation 

Automation  is 

Automation 

Automation 

Human  operator 

responsible  to  gather 

the  prime  source 

generates 

displays  up  to 

executes  by  minimal 

data  via  internal  and 

for  analysis, 

decision(s)  to 

5  COAs  in 

physical  interaction 

external  sensors;  has 

displaying 

be  made  and 

random  order. 

(e.g.  1-2  switch 

primary  control  over 

rudimentary 

COAs. 

Human  selects 

actuation  or  button 

sensors  to  scan  and 

results  to 

Displays  up  to 

from  this  list, 

presses). 

observe.  Displays 

monitoring 

5  COAs  for 

or  from  his/her 

Automation  ‘agents’ 

unfiltered. 

operators. 

each  decision 

own  list  of 

track  user  interaction 

unprioritized  data  to 

Human  operator 

in  random 

COAs. 

with  computer  and 

human  operator; 

responsible  for 

order  to  human 

execute  all  sub-tasks 

displays  status  of  sub- 

all  prediction, 

operator  (by 

automatically  (i.e. 

systems  (sensors, 

interpretation. 

design,  or  if 

batch  processing). 

weapons,  comm,  links. 

and  integration. 

ranking 

CTP/COP).  Human  is 

algorithm  not 

still  the  prime  monitor 

available). 

of  all  data;  augments 

Human  may 

automation  with  own 

generate 

sensory  receptors. 

additional 

Human  has  the  ability 

decision(s)  and 

to  take  over  sensor 

COA(s)  for 

placement  from 

input  to 

automation. 

computer. 
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Information 

Information 

Generation 

Decision(s) 

Action 

Level 

Acquisition 

Analysis 

Selection 

Implementation 

Human  is  the  prime 

Human  is  the 

Automation 

Automation 

Human  operator 

source  for  sensing, 

prime  source  for 

generates 

displays 

executes  by 

monitoring,  and 

analysis, 

decision(s)  to 

complete  set  of 

extensive,  indirect 

prioritizing  data. 

prediction. 

be  made  and 

decision/ 

physical 

Human  positions 

interpretation. 

COAs. 

action 

manipulation  of 

sensors  (own,  internal. 

and  integration 

Displays  full 

alternatives. 

necessary  sub- 

and  external)  as  part  of 

of  data  into 

list  of  COAs 

Human  selects 

systems  (e.g. 

selection  attention;  has 

information. 

for  each 

COA  from  the 

teleoperation, 

full  control  of  sensors 

Automation  only 

decision  in 

full  list,  or 

remote  operations, 

in  order  to  scan  and 

displays  raw 

random  order 

from  own  list 

slaving  of  human 

observe.  Automation 

data  values  from 

to  human 

of  COAs. 

physical  action. 

2 

tracks  status  of  relevant 

sensors  and  links 

operator  (by 

virtual 

sub-systems  (sensors, 

to  help  human 

design,  or  if 

environments). 

CTP/COP,  weapons, 

operator. 

ranking 

comm  links)  but  does 

algorithm  not 

not  display;  shadows 

available). 

for  emergencies(?). 

Human  may 
generate 
additional 
decision(s)  and 
COA(s)  for 
input  to 
computer. 

Human  is  the  only 

Human  performs 

Human 

Human  selects 

Human  operator 

source  for  sensing  and 

all  perception 

operator 

choice  from 

carries  out  the 

registration  of  input 

and  cognitive 

generates 

his/her  own  list 

decision,  directly 

data;  fdters,  prioritizes, 

processing, 

decision(s)  to 

of  COAs,  with 

and  physically 

understands. 

making 

be  made  and 

no  assistance 

implementing  all 

predictions  and 

the  available 

from 

aspect  of  the  chosen 

interpretation  of 

COAs.  No 

automation. 

action  with  no 

1 

data,  or 

assistance  from 

interaction  or  help 

integrating 
several  variables 
into  a  single 
value.  No 
information 
available  from 
automation. 

automation. 

from  automation. 

Referring  back  to  Figure  7,  let’s  look  at  the  examples  of  Functions  A/A'  and 
Systems  B/B'  on  the  graphical  scheme.  Function  A  might  represent  one  proposed  way  to 
describe  the  human-automation  interaction  for  this  particular  function  as  it  proceeds  from 
information  acquisition  to  analysis  and  on  through  to  decision  selection  and  action. 
System  designers  have  deliberately  designed  this  interaction  as  a  way  to  understand  how 
the  two  components  will  interact,  and  also  to  conceptually  understand  what  exactly  the 
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automation  should  be  designed  and  built  to  do  as  it  aids  the  human  operator.  However, 
they  also  would  like  to  look  at  the  alternative  of  Function  A',  another  way  of  deliberately 
describing  the  interaction.  This  example  shows  the  utility  of  the  proposed  model  as 
modified  from  Parasuraman  et  al.  (2000)  for  the  MGV  fleet.  The  graphical  representation 
of  human-automation  interface  makes  it  particularly  easy  to  envision  the  overarching 
functional  architecture  of  a  system  or  function  to  understand  exactly  how  a  human  will 
interact  with  the  proposed  automation.  Like  the  slider  bars  on  your  stereo  equalizer,  the 
designers  could  simply  ‘slide  down’  the  LOA  on  several  of  the  functions.  Combined  with 
the  descriptors  in  Table  6,  designers  can  clearly  understand  the  new  relationship  between 
human  and  automation  throughout  the  entire  Function  A J  A'.  Likewise,  System  B/B' 
may  represent  a  much  smaller  system  that  can  be  looked  at  as  whole  from  information 
acquisition  through  to  the  decision  and  action  stages.  In  this  case,  designers  might  be 
thinking  about  introducing  more  automation  to  the  small  system,  and  can  use  the 
graphical  representation  in  Figure  7  along  with  the  descriptors  in  Table  7  to  better 
understand  the  resulting  relationship  between  human  and  automation  in  their  new 
proposal. 

B.  APPLICATION  OF  MODEL  TO  MGV  FUNCTIONAL  FLOW 

The  next  step  in  the  thesis  is  to  exhibit  how  the  proposed  qualitative  model  might 
be  applied  against  the  functional  flow  that  describes  MGV  operations.  The  human 
factors  group  at  BAE-SC  has  developed  a  FA/TA  and  functional  flow  for  the  CCS  of  the 
MGV  fleet.  The  FA/TA  provides  an  overall  reference  on  how  the  Anny  and  the  V.I. 
envision  the  total  vehicle  system  to  operate.  As  such,  the  FA/TA  is  currently  indifferent 
as  to  the  allocation  of  functions  and  tasks  between  the  hardware/software  components  of 
the  system  and  the  human  crew.  Using  the  FA/TA  and  functional  flow  provided  from 
BAE-SC  engineers,  Figure  8  shows  a  top-level  view  of  the  five  functions  envisioned  for 
the  CCS  in  what  is  being  called  the  Common  Function  Model  (CFM).  The  five  functions 
thought  to  be  common  to  the  entire  MGV  fleet  are  vehicle  movement  (driving), 
communication,  vehicle  commander’s  awareness,  driver’s  local  surveillance,  and  local 
defense.  This  thesis  will  focus  on  applying  the  proposed  qualitative  human-automation 

interaction  model  to  the  last  of  these,  the  Local  Defense  function. 

44 


Figure  8.  CFM  Function  Flow  -  Level  1 . 


Figure  9  shows  a  further  decomposition  of  the  functional  flow  to  a  secondary  tier 
that  will  be  called  level  two.  Notice  that  the  Function  5  (Local  Defense)  has  two 
subfunctions  called  Acquire/Track  Threat  and  Engage  Threat. 
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Figure  9.  CFM  Functional  Flow  -  Level  2 
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Figure  10  shows  a  third-tier  decomposition  of  the  Local  Defense  only  into  a  series 
of  tasks;  this  is  the  final  decomposition.  The  tasks  contained  in  Function  5.1 
(Acquire/Track  Threat)  are  displayed  underneath  its  bubble,  as  are  the  tasks  for  Function 
5.2  (Engage  Threat).  The  tasks  involved  preparing  and  transmitting  a  digital  SITREP 
(situation  report)  are  repeated  in  both  tasks  depending  on  the  flow. 
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Figure  10.  CFM  Functional  Flow  -  Level  3  -  Function  5.0  (Local  Defense) 
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Figure  1 1  goes  one  step  further  to  collect  the  decomposed  tasks  into  groups  that 
adhere  to  the  information  processing  model  proposed  in  Table  5. 
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Figure  11.  Local  Defense  (CFM  Function  5.0),  with  tasks  decomposed  and  grouped 
in  accordance  with  the  proposed  information  processing  flow  model 


Using  the  functional  flow  for  Local  Defense  graphically  shown  in  Figure  11,  the 
next  step  is  to  then  apply  it  against  the  proposed  model  for  MGV  human-automation 
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interaction  shown  in  Figure  7.  The  result  is  the  proposed  schematic  in  Figure  12.  Here 
we  can  begin  to  understand  the  possible  relationship  between  human  and  automation  in 
the  Local  Defense  function. 
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Figure  12.  Local  Defense  (CFM  5)  decomposed  into  the  proposed  qualitative  model 


At  this  point  in  the  process,  we  can  now  begin  to  purposely  design  the  interaction 
between  the  human  operators  and  a  conceptual  automation  scheme,  or  to  quote 
Parasuraman  et  ah,  we  can  begin  to  ask  “what  level  of  automation  should  be  applied 
within  each  functional  domain.  There  is  no  simple  answer  to  this  question,  and  tradeoffs 
between  anticipated  benefits  are  likely”  (2000,  p.  289).  The  graphical  model  in  Figure  12 
and  the  descriptors  in  Table  7  are  proposed  as  a  guiding  framework.  Evaluative  criteria 
will  be  discussed  below,  but  three  clusters  of  sources  can  help  to  begin  the  process.  The 
first  is  prior  empirical  research,  such  as  that  reviewed  earlier  from  Kaber  and  Endsley 
(2004)  and  Ruff  et  al.  (2002).  “To  take  a  hypothetical  example,  suppose  prior  research 
has  shown  (or  modeling  predicts)  that,  compared  to  manual  operation,  both  human  and 
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system  performance  are  enhanced  by  level  4  automation  but  degraded  by  automation 
above  level  6”  (Parasuraman  et  al,  2000,  p.  290).  This  could  serve  as  an  initial 
specification  for  the  upper  and  lower  bounds  of  automation  in  a  certain  function. 
Research  sources  include  the  writings  from  experienced  researchers  in  the  field  who  have 
delved  into  real  automation  and  resulting  human  accidents,  such  as  Billings  (1997), 
Norman  (1990),  Woods  and  Sarter  (1998).  The  second  cluster  looks  to  Army  doctrine 
and  past  experience  from  tactics,  techniques  and  procedures  (TTPs),  which  can  guide  us 
as  to  understanding  what  has  (and  has  not)  worked  in  past  and  current  systems.  Closely 
related  is  the  third  cluster,  input  from  subject  matter  experts  (SMEs).  SMEs  may  be  real 
soldiers  who  work  in  the  combat  development  or  material  development  structures  for  the 
Army.  They  can  also  include  the  experience  and  expertise  of  scientists  and  engineers  who 
have  been  involved  in  systems  design  in  the  past,  particularly  human  factors  specialists. 

Therefore,  to  further  the  ideals  of  this  thesis,  Figure  13  graphically  presents  two 
possible  human-automation  interface  schemes  to  achieve  the  common  function  of  Local 
Defense.  The  current  scheme  (yellow  line  on  the  graph)  employs  almost  no  automation 
at  all,  only  giving  the  vehicle  commander  some  physical  aids  to  allow  arming  and  firing 
of  the  chosen  weapon  with  a  single  button  press.  The  vehicle  commander  is  totally 
responsible  for  detecting,  identifying,  and  tracking  any  local  threats.  Unfortunately,  the 
common  FA/TA  provided  by  BAE-SC  does  not  account  for  the  COA  Development  stage 
proposed  in  this  thesis,  so  it  is  skipped  and  simply  left  at  full  manual  control.  In  the 
Engagement  stage,  the  commander  must  then  make  a  series  of  decisions  (probably  in 
rapid  order)  that  starts  with  whether  to  engage  the  target  or  not,  followed  by  selections  of 
the  appropriate  weapon  and  ammunition.  At  the  Shoot/Report  stage,  automation  design 
gives  the  commander  some  physical  help  by  only  requiring  a  simple  button  press  to  arm 
the  chosen  weapon,  and  then  another  single-button  press  to  fire  the  weapon.  Preparation 
and  transmission  of  the  digital  (i.e.  typed  text)  situation  report  is  left  completely  with  the 
commander. 
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FCS  Manned  Ground  Vehicle  Fleet  (Common  Crew  Station) 
Local  Defense  (CFM  5):  Acquire/Track/Enqaqe  Threat  (CFM  51-52) 
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Figure  13.  Qualitative  Model  Applied  to  the  Local  Defense  Function 


In  contrast  to  the  current  scheme,  a  new  proposal  for  human-automation  is 
graphically  represented  in  Figure  13  with  the  red  line.  Notice  that,  per  the  description  of 
the  model  in  Figure  7,  the  ‘slider  bars’  are  up  to  higher  LOAs  for  certain  tasks  in  the 
Local  Defense  function.  The  new  proposal  blends  some  prior  research,  some  SME  input, 
and  some  human  factors  knowledge. 

Starting  with  the  Detection  and  Identification  tasks,  the  interface  is  moved  up  to 

LOA-3  in  accordance  with  the  descriptors  in  Table  6.  Upon  reflection  about  the  Tracking 

task,  it  was  decided  that  the  soldier  simply  monitoring  any  proposed  automation  would 

require  just  as  much  mental  workload  effort  and  doing  it  himself,  so  it  is  left  unchanged. 

Moving  to  the  Engagement  tasks,  the  human  will  get  some  help  in  making  the  decision  to 

engage  or  not.  After  that,  it  is  hypothesized  that  an  intelligent  automation  scheme  would 

quickly  make  the  correct  recommendation  for  the  appropriate  weapon  and  ammunition 

based  on  sensor  data.  If  the  commander  decides  not  to  engage  the  target,  he  would  move 
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straight  away  to  the  SITREP  preparation  and  transmission.  Finally,  as  the  functional  flow 
continues,  computer  software  would  ask  the  commander  if  he  wants  to  ann  the  chosen 
weapon.  Then  the  commander  can  fire  the  weapon  with  a  single  button  press  (no  change 
from  the  current  scheme).  To  end  the  sequence,  the  commander  would  get  considerable 
aid  in  preparing  and  transmitting  the  SITREP,  a  big  change  from  the  current  system.  Of 
course,  the  entire  sequence  feeds  back  on  itself  and  repeats,  as  dictated  by  the  operational 
situation. 

There  are  four  dashed  arrows  in  the  proposed  human-automation  scheme  that 
require  some  explanation.  For  the  two  decisions  at  LOA-7,  the  proposed  interface  would 
entail  the  computer  making  a  recommendation  to  the  vehicle  commander  for  a  yes-or-no 
decision.  If  the  human  accepts  the  recommendation,  the  next  task  occurs.  However,  for 
these  two  decision  tasks,  if  the  commander  rejects  the  recommendation,  then  the  scheme 
reverts  to  LOA-1,  the  same  as  the  current  scheme.  For  the  task  of  anning  the  chosen 
weapon,  a  similar  scheme  results.  If  the  vehicle  commander  decides  to  reject  (or 
override)  the  arming  of  the  weapon,  then  the  interaction  reverts  to  LOA-1.  Lastly,  the 
computer  will  prepare  a  SITREP  based  on  available  data  and  transmit  automatically 
unless  the  commander  rejects  (or  overrides)  the  preparation/transmission  task,  causing  a 
reversion  to  LOA- 1 . 

The  white  boxes  at  the  bottom  of  each  of  the  five  stages  in  Figure  1 1  depict  basic 
pieces  of  information  about  what  might  be  displayed  to  the  vehicle  commander  at  that 
stage  of  the  functional  flow.  In  the  Detection  stage,  the  commander  will  probably  need  to 
see  the  proper  symbology  of  all  targets,  the  status  of  his  vehicle’s  sensors,  and  status  of 
the  common  operational  picture  (COP),  common  tactical  picture  (CTP),  and  any 
communications  links  to  the  network.  In  the  Identification/Track  tasks,  the  commander 
will  likely  need  to  have  further  information  about  the  target,  such  as  location,  bearing, 
speed,  even  altitude.  Infonnation  for  any  of  these  stages  may  come  from  the  vehicles  own 
sensors,  from  the  COP,  or  over  the  network.  In  the  COA  Development  stage,  the 
commander  will  need  to  see  the  possible  CO  As,  depending  on  the  LOA  used.  In  a  slight 
shift,  the  white  boxes  below  the  Engagement  and  Shoot/Report  tasks  each  delineate 
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exactly  what  decisions  have  to  be  made,  and  what  actions  must  be  carried  out.  These 
decisions  and  actions  can  be  accomplished  by  the  soldier-automation  team. 


C.  APPLICATION  OF  MODEL  TO  LITTORAL  COMBAT  SHIP 

The  example  detailed  in  the  previous  section  is  for  only  one  function  of  the 
common  crew  station  for  the  MGV  fleet.  In  an  attempt  to  provide  the  reader  with  another 
example  of  how  this  process  might  be  carried  out  in  another  domain.  Appendix  B  of  this 
thesis  contains  an  example  of  the  Parasuraman  et  al.  (2000)  model  of  human-automation 
interface  applied  to  the  US  Navy’s  Littoral  Combat  Ship. 

The  paper  included  in  the  Appendix  was  developed  as  a  conceptual  project  for  a 
course  in  Systems  Engineering  and  Integration  at  the  Naval  Postgraduate.  The  paper  was 
published  in  the  proceedings  of  the  2005  Human  Systems  Integration  Symposium  (see 
Kennedy,  Thomas,  &  Green,  2005). 


D.  EVALUATIVE  CRITERIA 

Borrowing  once  again  from  Parasuraman,  Sheridan,  and  Wickens  (2000),  any 
particular  “level  of  automation  should  be  evaluated  by  examining  its  associated  human 
performance  consequences.  However,  human  perfonnance  is  not  the  only  important 
factor.  Secondary  evaluative  criteria  include  automation  reliability  and  the  costs  of 
decision/action  consequences”  (p.  289),  though  others  may  include  ease  of  systems 
integration,  efficiency/safety  tradeoffs,  issues  of  operators,  and  more.  “These  should  be 
applied  to  evaluate  the  feasibility  and  appropriateness  of  particular  levels  of  automation” 
(p.289),  done  in  an  iterative  process.  They  emphasize,  however,  that  the  model  should  not 
be  treated  as  a  static  formula  or  as  a  prescription  that  decrees  a  particular  type  or  level  of 
automation.  Rather,  when  considered  in  combination  with  primary  and  secondary 
evaluative  criteria,  the  model  they  provided,  and  expanded  in  this  thesis,  “can  provide 
principled  guidelines  for  automation  design”  (p.  289). 

1.  Primary  Criteria 

Over  the  past  25  years,  researchers  have  found  that  automation  can  have  both 
beneficial  and  negative  effects  on  human  performance.  There  are  four  main  human 


53 


performance  areas  recommended  by  Parasuraman  et  al.  (2000)  as  primary  evaluative 
criteria:  mental  workload  (MWL),  SA,  complacency,  and  skill  degradation.  Evidence 
suggests  that  well-designed  information  automation  can  change  MWL  to  a  level  that  is 
appropriate  for  the  systems  tasks  being  performed.  However,  “clumsy”  automation  can 
lead  to  increasing  workload  (2000).  As  will  be  discussed  below,  MWL  can  be  modeled 
during  system  design  to  assess  if  it  is  reasonable  throughout  system  functional  flow. 

Besides  unbalanced  MWL,  automation  can  incur  human  perfonnance  costs  in  the 
other  three  criteria  suggested.  Situation  awareness  can  be  negatively  affected  when  the 
operators  loses  “awareness  of  the  system  and  certain  dynamic  features  of  the  work 
environment”  (2000,  p.  291).  If  the  MGV  automation  scheme  is  highly  but  not  perfectly 
reliable  in  executing  the  major  decision  choices,  “then  the  operators  may  not  monitor  the 
automation  and  its  information  sources  and  hence  fail  to  detect  the  occasional  times  when 
then  automation  fails”  (2000,  p.  291)  or  is  wrong.  Complacency  is  greatest  in  high  MWL 
setting  when  the  operator  is  engaged  in  multiple  tasks.  Third,  skill  degradation  can 
certainly  occur  over  time  if  the  system  decisions  are  routinely  carried  out  by  the 
automation.  “These  potential  costs — reduced  situation  awareness,  complacency,  and  skill 
degradation — collectively  demonstrate  that  high-level  automation  can  lead  to  operators 
exhibiting  out-of-the-loop  unfamiliarity.  All  three  sources  of  vulnerability  may  pose  a 
threat  to  safety  in  the  system  failure”  (2000,  p.  291).  The  MGV  automation  design  must 
demonstrate  that  potential  human  performance  costs,  along  with  unbalanced  MWL,  do 
not  occur.  “By  considering  these  human  performance  consequences,  the  relative  merits  of 
a  specific  level  of  automation  can  be  determined”  (2000,  p.  291). 

2.  Secondary  Criteria 

Secondary  evaluative  criteria  can  include  automation  reliability  and  the  cost  of 
decision  and  action  outcomes.  Reliability  is  typically  defined  in  probabilistic  terms,  such 
as  a  reliability  of  .997  or  a  mean  time  to  failure  of  10,000  hours.  In  addition,  “failures 
may  occur  not  because  of  a  predictable  (in  a  statistical  sense)  malfunction  in  software  or 
hardware,  but  because  the  assumptions  that  are  modeled  in  the  automation  by  the 
designer  are  not  met  in  a  given  operational  situation”  (2000,  p.292).  The  reliability  of 
automation  also  influences  human  trust,  possibly  undennining  potential  system 
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performance  benefits  when  the  automation  is  underused  or  disabled.  In  addition  to 
reliability,  “assessing  the  appropriate  level  of  automation  for  decisions  requires  additional 
consideration  of  the  costs  associated  with  decision  and  action  outcomes”  (2000,  p.  292; 
see  also  Lee  and  See,  2004). 
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IV.  THE  HUMAN-AUTOMATION  INTERFACE  MODEL  IN 
ACTION:  A  QUANTITATIVE  IMPLEMENTATION  VIA  IMPRINT 

A.  NEED  FOR  QUANTITATIVE  MODELS 

Parasuraman  et  al.  (2000)  correctly  argue  for  the  primary  evaluative  criteria  as 
part  of  the  design  process  for  a  human-automation  interaction  scheme.  As  discussed  in 
Chapter  II  of  this  thesis,  Parasuraman  (2000)  also  argued  for  the  development  of 
quantitative  models  that  could  inform  the  design  of  human-automation  interaction, 
pointing  out  several  computational  and  formal  models  of  human  interaction  with 
automation. 

This  thesis  implemented  the  qualitative  model  applied  to  the  MGV  (per  Chapter 
III)  via  a  computational  analysis  using  task-network  modeling  and  Monte  Carlo 
simulation  from  a  software  called  IMPRINT  (see  below  for  details).  This  demonstration 
is  a  way  to  quantitatively  predict  human  task-loading  attempts  to  evaluate  the  primary 
criterion  of  mental  workload.  There  is  one  example  in  the  literature  from  Parasuraman  et 
al.  (2005)  where  a  automation  scheme  has  been  modeled  via  a  computational  task- 
network  model.  In  the  study,  the  research  team  investigated  the  effects  of  a  delegation- 
type  interface  on  human  supervision  of  multiple  unmanned  vehicles.  As  part  of  the 
experimentation  program,  they  conducted  analysis  via  WinCrew  to  carry  out  a  mental 
workload  prediction  (personal  communication,  Dr.  Hiroshi  Furukawa,  20  Sep  05). 
WinCrew  is  a  precursor  to  the  program  MicroS AINT,  which  is  the  heart  of  ARL/HRED’s 
IMPRINT  software.  The  Parasuraman  et  al.  (2005)  paper  provided  the  inspiration  to 
demonstrate  the  proposed  MGV  human-automation  guidelines  in  IMPRINT. 


B.  IMPROVED  PERFORMANCE  RESEARCH  AND  INTEGRATION  TOOL 
(IMPRINT) 

IMPRINT  is  a  stochastic  network-modeling  tool  designed  to  help  assess  the 
interaction  of  soldier  and  system  perfonnance  from  concept  and  design  through  field 
testing  and  system  upgrades.  An  important  feature  of  IMPRINT  is  that  it  helps 
researchers  and  designers  evaluate  operator  and  crew  mental  workload  while  testing 
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alternate  system-crew  function  allocations.  The  amount  of  mental  workload  that  is 
required  to  use  a  system  has  a  significant  effect  on  human  performance  within  the 
system.  IMPRINT  gives  system  designers  the  information  they  need  to  predict  how 
changes  in  design  can  affect  overall  system  performance.  Since  FCS  is  still  early  in  the 
design  phase,  IMPRINT  is  a  very  suitable  tool  to  use  (Mitchell,  Samms,  Henthom,  & 
Wojciechowski,  2003;  Mitchell,  2005). 

One  major  function  of  IMPRINT,  via  task-network  modeling,  is  to  predict 
operator  task-loading  using  cognitive  resources  (visual,  auditory,  cognitive,  motor,  and 
speech)  and  Monte  Carlo  simulation.  This  provides  quantitative  values  for  total 
momentary  workload  based  on  the  estimates  of  cognitive  resources  provided  by  the 
analyst.  The  IMPRINT  methodology  has  a  long  history  in  the  Anny,  originated  during 
the  early  days  of  the  LHX  program  as  discussed  in  Chapter  II.  Without  a  doubt,  the 
accuracy  and  precision  of  the  modeling  results  depend  on  the  skill  and  experience  of  the 
analyst  (as  they  say,  Garbage  In — Garbage  Out).  However,  it  is  a  well  accepted  modeling 
methodology  in  use  by  multiple  Army  (and  DoD)  programs. 

The  task-network  model  in  IMPRINT  is  generally  run  for  a  set  period  of  time; 
anywhere  from  one  minute  to  several  hours,  depending  on  the  needs  of  the  analyst.  The 
models  generated  for  this  thesis  were  set  to  run  for  60  minutes.  To  run  the  simulation  for 
the  set  time,  the  analyst  provides  a  random  number  seed  to  the  program,  an  integer  from 
1-100,000.  In  effect,  the  random  number  seeds  simulate  the  variation  that  would  normally 
be  provided  by  different  human  subjects.  IMPRINT  provides  a  host  of  numerical  results 
straight  to  Microsoft  Excel  for  further  scrutiny.  Chief  among  these  is  the  total 
momentary  workload  score  calculated  each  time  a  tasks  begins  or  ends.  The  advanced 
workload  feature  of  IMPRINT  used  in  this  analysis  calculated  workload  based  on  the 
cognitive  resources  being  used  by  the  operator,  and  incorporates  the  fact  that  multiple 
tasks  are  being  performed  simultaneously. 

Previous  technical  reports  and  publications  from  ARL/HRED  using  IMPRINT 
have  incorporated  a  workload  ‘threshold’  value  where  the  operator  was  considered  to  be 
a  state  of  ‘high’  or  ‘very  high’  workload.  This  concept  of  a  workload  threshold  goes 
back  to  the  original  LHX  analysis  from  McCracken  and  Aldrich  (1984).  The  IMPRINT 
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workload  value  of  60  has  been  used  by  a  consensus  of  workload  modeling  SMEs  to 
represent  the  ‘high’  threshold,  while  the  workload  value  of  100  is  equivalent  to  the  ‘very 
high’  threshold  (Mitchell,  Samms,  Henthorn,  &  Wojciechowski,  2003;  Mitchell,  2005). 

Previous  technical  analysis  by  IMPRINT  modelers  for  the  FCS  MGV  fleet  has 
yielded  five  metrics  of  use  in  the  IMPRINT  analysis:  1)  maximum  momentary  workload 
calculated  during  the  data  run,  2)  number  of  times  in  the  simulation  run  that  workload 
exceeded  60  (high),  3)  number  of  times  that  workload  exceeded  100  (very  high),  4)  the 
percentage  of  time  spent  over  the  high  threshold,  and  5)  the  percentage  of  time  spent  over 
the  very  high  threshold.  These  five  metrics  are  used  in  this  thesis. 

C.  MGV  COMMON  FUNCTION  MODEL  (CFM) 

IMPRINT  analysts  with  ARL/HRED,  the  FCS  LSI  (Boeing,  SAIC)  and  the  V.I. 
team  (BAE  and  GDLS)  have  developed  a  CFM  based  on  the  CCS  FA/TA  discussed 
earlier.  The  CFM  model  is  generally  approved  by  all  of  the  analysts  involved  in  the 
project,  and  has  been  through  the  scrutiny  of  multiple  SMEs  to  ensure  it  is  a  valid 
representation  of  the  task-network  and  functional  flow  anticipated  for  crews  in  the  CCS 
of  the  MGV  fleet.  This  model,  provided  by  analysts  from  BAE  to  the  author,  acts  as  the 
baseline  for  the  task-loading  analysis  in  this  thesis. 

Using  the  proposed  scheme  in  Figure  13,  the  Local  Defense  function  (CFM5)  of 
the  baseline  was  modified  to  reflect  the  new  and  resulting  human-automation  scheme  by 
‘dialing  in’  selected  levels  of  automation  for  selected  tasks.  The  exact  task-network 
changes  are  not  reproduced  here,  but  Figure  14  is  provided  to  give  the  reader  an 
understanding  of  how  the  Local  Defense  task-network  in  the  CFM  was  modified  to 
account  for  the  proposed  human-automation  interaction.  The  full  task-network  model  is 
available  electronically  from  the  author  on  request. 
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While  IMPRINT  is  a  great  tool  for  early  analysis,  it  cannot  fully  capture  the 
nuances  of  the  proposed  human-automation  interface  in  the  estimates  of  cognitive 
resources,  task  completion  times,  etc.  IMPRINT  is  limited  in  its  ability  to  fully  model  the 
interaction  and  subsequent  operator  human,  but  its  results  do  provide  some  bounds  and 
guidance  on  the  real  problem  of  crew  size  and  paired  human-automation  behavior  in  the 
MGV  fleet. 
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To  collect  baseline  data  for  the  analysis,  the  simulation  was  run  for  60  minutes.  A 
set  of  random  number  seeds  were  generated  in  Microsoft  Excel  for  use  in  the  random 
number  seed  part  of  the  simulation.  After  inputting  the  random  number  seed  and 
executing  the  baseline  CFM  model,  it  took  approximately  2-5  minutes  to  complete  the 
simulation  and  generate  the  data  into  Excel.  Then  another  random  seed  was  entered  and 
the  simulation  run  again,  continuing  this  process  a  dozen  times  to  get  a  set  of  usable  data 
that  the  author  felt  comfortable  with. 

As  with  the  baseline  CFM  model,  simulation  was  run  for  60  minutes  to  permit 
side-by-side  comparison  of  the  five  workload  metrics.  However,  completing  the  data 
runs  for  the  modified  CFM  was  a  much  longer,  more  involved  process.  First  attempts  at 
modifying  the  CFM  involved  breaking  each  baseline  tasks  into  two  or  more  tasks,  which 
were  carried  out  by  human  and  automation  in  parallel  in  the  task  network.  The  subtasks 
assigned  to  automation  were  carried  out  without  error  in  no  time  and  with  no  workload 
channel  values.  The  sub  tasks  assigned  to  the  human  were  given  modified  workload 
channel  values  based  on  the  nature  of  the  resulting  interaction  with  automation.  This 
process  of  assigning  new  tasks  and  workload  values  carries  as  much  ‘art’  as  it  does 
‘science’.  It  is  entirely  up  to  the  modeler,  with  his  experience  and  expertise,  to  guide  the 
process.  After  some  early  data  runs,  the  author  realized  the  method  of  having  the 
subtasks  in  parallel  was  causing  unintelligible  results:  all  of  the  workload  results  were  in 
the  many,  many  times  in  excess  of  the  baseline  CFM  scores,  indicating  a  serious  problem 
with  the  veracity  of  the  model. 

Realizing  this  was  an  error,  the  author  then  shifted  to  running  the  resulting 
subtasks  in  serial.  Repeated  modifications  of  the  model  and  about  an  additional  60  data 
runs  were  necessary  before  IMPRINT  yielded  intelligible  results.  Further  modifications 
to  the  task-network  eventually  were  necessary  to  capture  the  some  of  the  intricacies  of  the 
proposed  human-automation  interaction  and  predicted  task-loading  (i.e.,  MWF,  a  key 
component  of  human  perfonnance).  All  told,  the  author  completed  over  250  data  runs. 

Once  the  author  was  comfortable  with  the  execution  of  the  modified  CFM,  the 
author  ran  another  set  of  eleven  data  runs  using  the  same  random  number  seeds  as  the 
baseline  analysis,  and  then  tabulated  the  scores  for  five  chosen  metrics.  In  effect,  using 
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the  same  random  seeds  simulated  using  the  same  human  subjects  for  both  the  baseline 
and  modified  CFM.  This  is  a  key  variance  reduction  technique,  and  allowed  a  side-by- 
side  comparison  of  the  baseline  CFM  versus  the  modified  CFM. 

D.  PLAN  FOR  QUANTITATIVE  ANALYSIS 

Given  the  baseline -modification  plan  of  action,  the  plan  for  data  analysis  was 
straightforward.  In  this  case,  the  baseline  CFM  and  the  proposed  modifications  represent 
a  classic  ‘before-after’  comparison,  and  the  paired  /-test  is  appropriate.  The  data  for  the 
five  metrics  collected  above  (maximum  workload,  number  of  time  over  60  and  100, 
percent  of  time  over  60  and  100)  were  compared  via  the  paired  /-test.  The  data  certainly 
displayed  interval/ratio  scale  properties.  The  assumption  of  normality  in  the  paired 
differences  was  reasonable  for  three  of  the  metrics,  but  somewhat  weak  for  two  others. 
Thus,  the  five  before-after  metrics  were  also  compared  via  the  equivalent  nonparametric 
inferential  statistic,  the  Wilcoxon  Signed  Ranks  Test  (WSRT).  The  conclusions  were  the 
same  regardless  of  the  test  conducted. 
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V.  RESULTS  OF  QUANTITATIVE  ANALYSIS  VIA  IMPRINT 


Eleven  data  runs  were  conducted  each  for  the  baseline  MGV  CFM  as  well  as  the 
modified  CFM  with  the  proposed  human-automation  interface  scheme  out  of  Figure  11. 
Table  8  shows  the  tabulated  results  from  the  baseline  CFM,  while  Table  9  shows  the 
tabulated  results  for  the  modified  CFM.  Each  simulation  run  was  conducted  eleven  times 
with  the  common  random  number  seeds.  The  sample  mean  and  standard  deviation  are  at 
the  bottom  of  each  table  to  gain  an  understanding  of  the  variability  in  the  data. 


Table  8.  Analysis  of  Baseline  ’ 

MGV  CFM 

Run 

Maximum 

Workload 

Number  of  Times 
Workload 
Exceeds  (>)  60 

Number  of 
Times  Workload 
Exceeds  (>)  100 

Percent  of  Time 
Over  High 
Threshold  (>  60) 

Percent  of  Time 
Over  Verv  High 
Threshold  (>  100) 

1 

297.26 

792 

401 

46.22% 

21.44% 

2 

428.76 

751 

449 

49.15% 

24.72% 

3 

451.88 

1055 

723 

64.58% 

39.36% 

4 

589.65 

2614 

2254 

85.94% 

72.65% 

5 

1100.08 

3381 

3200 

87.03% 

80.25% 

6 

412.11 

847 

469 

49.02% 

24.15% 

7 

213.33 

627 

233 

35.32% 

11.43% 

8 

353.92 

1222 

820 

67.24% 

40.75% 

9 

586.23 

926 

588 

52.84% 

31.63% 

10 

284.02 

581 

232 

34.01% 

11.68% 

11 

431.67 

812 

514 

49.22% 

28.48% 

X 

468.08 

1237 

898 

56.41% 

35.14% 

s 

245.70 

941 

981 

18.57% 

23.26% 

Comparison  of  the  five  metrics  via  paired  /-test  yielded  statistically  significant 
differences  in  four  of  the  five  metrics  (Table  9).  The  number  of  times  workload  exceeded 
60  and  100,  and  the  percentage  of  time  workload  was  over  60  and  100,  were  significantly 
lower  in  the  modified  CFM  than  in  the  baseline  CFM.  The  difference  in  maximum 
workload  was  not  significant. 
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Table  9.  Analysis  Results  of  Proposed  Human-Automation  Interface  Scheme 


Applied  to  MGV  CFM 


Run 

Maximum 

Workload 

Number  of  Times 
Workload 
Exceeds  (>)  60 

Number  of  Times 
Workload 
Exceeds  (>)  100 

Percent  of  Time 
Over  High 
Threshold  (> 

60) 

Percent  of  Time 
Over  Very  High 
Threshold  (>  100) 

1 

270.14 

538 

231 

34.06% 

11.79% 

2 

382.25 

680 

372 

31.02% 

13.34% 

3 

675.88 

924 

585 

49.16% 

28.06% 

4 

444.44 

997 

655 

57.60% 

38.81% 

5 

808.38 

2568 

2311 

85.32% 

75.89% 

6 

497.86 

1170 

767 

65.72% 

38.38% 

7 

213.33 

603 

236 

33.45% 

10.91% 

8 

420.67 

803 

422 

44.47% 

21.06% 

9 

208.5 

479 

215 

30.21% 

11.61% 

10 

262.82 

487 

218 

27.83% 

10.39% 

11 

216.63 

485 

201 

27.05% 

9.98% 

X 

400.08 

885 

565 

44.17% 

24.57% 

s 

413.08 

920 

598 

45.18% 

25.84% 

able  10. Results  of  Comparison  by  Paired  /-test 


Metric 

Mean 

Difference 

SE  Mean 

t 

if 

y>value 

Maximum  Workload 

68.00 

53.05 

1.282 

10 

.229 

Number  of  Times  >  60 

352.182 

153.57 

2.293 

10 

.045 

Number  of  Times  >100 

333.636 

155.57 

2.145 

10 

.058 

Percent  of  Time  >  60 

12.24% 

3.95% 

3.102 

10 

.011 

Percent  of  Time  >100 

10.57% 

3.84% 

2.756 

10 

.020 

Since  the  assumption  of  normality  in  the  paired  differences  was  weak  in  two 
cases,  comparison  of  five  metrics  was  also  conducted  via  the  WSRT  (Table  10).  The 
conclusions  are  the  same  as  the  paired  /-test  results. 


Table  11. 


Results  of  Comparison  by  Wilcoxon  Signed  Ranks  Test 


Metric 

T 

p-value 

Maximum  Workload 

1.282 

.285 

Number  of  Times  >  60 

2.293 

.016 

Number  of  Times  >100 

2.145 

.021 

Percent  of  Time  >  60 

3.102 

.016 

Percent  of  Time  >100 

2.756 

.021 
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VI.  DISCUSSION 


A.  DO  NOT  OVEREMPHASIZE  THE  STASTICAL  RESULTS 

The  goal  of  this  thesis  was  to  provide  a  process  for  developing  a  top-down, 
overarching  approach  to  explicitly  define  and  design  the  interaction  between  proposed 
automation  schemes  and  the  human  crew.  It  shows  an  approach  to  developing  a 
functional  architecture  between  human  and  automation  for  the  total  system.  In  effect,  it 
constitutes  the  design  methodology  and  automation  philosophy,  as  espoused  by  Rouse  et 
al.  (1987).  While  it  was  developed  for  engineers  and  scientists  at  BAE  and  the  V.I.,  the 
process  can  be  expanded  to  a  wide  array  of  domains  (aviation,  space,  maritime,  ground 
transportation,  manufacturing,  etc.).  Chapter  III  covered  the  development  of  the 
qualitative  to  drive  the  design  process.  It  is  a  logical  approach  to  function  decomposition 
with  a  reasonable  paradigm  to  use  to  conceptualize  the  shared  roles  between  human  and 
automation.  With  this  tool  in  hand,  the  exact  role  of  the  Soldier  operators  as  the  central 
component  of  the  vehicle  systems  can  be  more  clearly  understood  well  before  the  fielding 
of  the  vehicle  systems. 

The  results  show  that  it  is  possible  to  gain  a  reduction  in  operators  task-loading, 
but  is  not  inevitable.  Using  IMPRINT,  we  associate  task-loading  with  the  construct  of 
mental  workload,  an  idea  that  cannot  be  easily  measured  under  any  circumstances.  The 
research  community  generally  accepts  MWL  as  a  key  facet  of  overall  human 
performance,  but  simply  lowering  MWL  will  not  necessarily  improve  human  (and  thus 
system)  performance.  Simply  adding  more  automation  will  not  automatically  decrease 
task-loading  and  mental  workload.  The  literature  review  in  this  thesis  should  convince 
the  reader  of  these  assertions. 

The  thesis  demonstrated  that  the  proposed  model  can  be  implemented  in 
IMPRINT  as  a  way  to  quantify  the  effects  of  the  proposed  human-automation  interface 
scheme  on  task-loading  predictions  (and  thus  mental  workload).  Only  the  Local  Defense 
function  of  the  CFM  was  quantitatively  modeled,  but  it  helps  us  gain  some  understanding 
of  the  human  performance  ramifications  of  the  proposed  model,  as  per  the  primary 
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evaluative  criteria  put  forth  by  Parasuraman  et  al.  (2000).  In  this  way,  we  can  take  a  step 
towards  reducing  workload  peaks  and  improving  human  performance. 

A  primary  conclusion  of  the  thesis  is  that  by  applying  the  proposed  human- 
automation  interface  model  to  other  functions  in  the  vehicles,  both  in  the  CFM  and  in 
vehicle-specific  function,  it  is  possible  to  make  further  reductions  in  operators  task¬ 
loading,  and  this  MWL.  This  will  also  support  attempts  to  achieve  the  current  ORD 
requirement  for  a  vehicle  operable  by  a  2-soldier  crew.  This  work  is  intended  to 
contribute  to  the  effort  to  ensure  that  vehicle  systems  in  the  MGV  fleet  can  accomplish 
the  overall  unit  mission  and  the  FCS’  mission  as  an  acquisition  program.  Even  if  we 
eventually  conclude  that  an  additional  crewmember  is  required  on  the  various  MGV 
vehicles,  the  same  qualitative  and  quantitative  models  can  be  used  to  gain  a  clear 
understanding  of  the  human-automation  interaction  as  well  as  the  some  of  the  human 
performance  ramifications  in  terms  of  mental  workload. 

Caution  should  be  taken  not  to  overemphasize  the  results  of  the  paired 
comparisons  in  the  Results.  Again,  the  goal  of  the  thesis  was  to  demonstrate  how  the 
proposed  interface  scheme  might  be  quantitatively  modeled.  There  are  many 
knowledgeable  IMPRINT  practitioners  who  can  improve  on  the  steps  taken  in  this  thesis 
to  quantify  the  possible  human  perfonnance  ramifications.  Echoing  previous  IMPRINT 
technical  reports  and  papers  (Mitchell,  20005;  Mitchell  et  al,  2003),  this  type  of 
quantitative  analysis  can  direct  the  engineer  and  researcher  towards  areas  of  task  demand 
in  new,  manned  systems  that  need  improvements. 

Another  key  point  to  make  about  the  possible  reductions  in  task-loading  (and 
thus,  MWL)  is  to  understand  that  they  are  possible  if,  and  only  if  it  is  possible  to  design 
the  automation  to  the  levels  recommended  in  the  proposed  model!  If  the  proposed 
automation  level  is  not  technically  feasible,  or  costs  too  much  to  achieve,  then  you  may 
not  be  able  to  achieve  the  predicted  operator  task-loading  predictions.  Should  engineers 
and  designers  be  forced  to  ‘dial  down’  the  LOA  for  a  function,  modifying  the  IMPRINT 
analysis  is  a  possible  way  to  understand  the  implications  on  task-loading,  and  thus 
possible  ramifications  for  human  performance. 


66 


There  is  a  final  note  of  caution  in  interpreting  the  results.  In  the  midst  of  making 
the  250+  data  runs  in  IMPRINT  with  the  different  random  number  seeds,  there  were 
several  cases  of  extreme  outliers  in  terms  of  calculated  task-load,  with  maximum 
workload  scores  reaching  in  excess  of  2000  on  one  or  two  occasions.  It  merely  goes  to 
show  that  IMPRINT,  while  a  wonderful  tool  for  analysis  of  systems  early  in  the  design 
process,  has  inherent  variability  and  that  multiple  runs  with  common  random  number 
seeds  are  necessary  achieve  accurate  estimates  of  workload. 

The  author  is  firmly  convinced  that  if  he  took  the  time  to  replicate  the  analysis 
over  40-50  data  runs  (with  common  random  number  seeds  to  reduce  variability  and 
induce  the  paired  /-test),  that  the  results  would  yield  at  least  3-5  severe  outliers  in  terms 
of  workload  score.  Post-hoc  analysis  of  some  outlier  cases  shows  that  the  simulated 
vehicle  commander  was  trying  to  accomplish  unrealistic  number  of  tasks  simultaneously. 
In  some  instances,  not  only  was  the  commander  conducting  various  tasks  in  the  Local 
Defense  function,  but  the  simulation  might  have  the  same  person  monitoring  the  driver, 
talking  on  the  intercom,  typing  a  digital  message,  and  more.  This  artificially  drives  the 
momentary  workload  score  into  unrealistic  totals.  In  real  operations,  the  vehicle 
commander  would  have  shed  and/or  prioritize  tasks  in  order  to  bring  his  workload  under 
some  semblance  of  control.  To  paraphrase  legendary  Frederick  Taylor,  the  ‘father  of 
scientific  management’,  he  would  be  required  to  have  too  many  hands,  too  many  feet, 
and  too  many  heads  (Taylor,  1957). 

Post-hoc  analysis  of  other  outlier  cases  reveals  another  situation  that  IMPRINT 
analysts  must  be  wary  of.  This  thesis  made  modification  to  only  the  Local  Defense  part 
of  the  CFM,  leaving  the  remaining  functions  unchanged.  There  was  one  case  during 
early  data  runs  where  a  certain  random  number  seed  simply  never  called  upon  the  Local 
Defense  function,  even  after  60  minutes  of  simulated  action.  In  that  case,  the  total 
workload  metrics  became  severe  outliers  because  the  simulation  never  called  on  the 
functions  where  automation  had  been  ‘dialed  in’  to  help  the  human  operator!  In  that 
case,  the  random  number  seed  and  its  results  were  discarded.  The  prudent  practitioner 
will  not  make  conclusions  from  only  a  single  data  run,  but  rather  after  at  least  10  data 
runs  to  gain  some  idea  of  the  variability  involved  the  simulation. 
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B.  WHAT  IMPRINT  DOES  NOT  ACCOUNT  FOR 

The  results  of  this  thesis  should  not  be  construed  as  an  argument  that  the  MGV 
fleet  can  be  operated  with  only  two  soldiers.  Nowhere  does  this  thesis  make  that 
argument  or  conclusion.  While  the  thesis  has  been  able  to  show  how  the  application  of 
the  qualitative  human-automation  interaction  model  can  bring  a  possible  reduction  in 
operator  task-loading  due  to  purposely  designed  automation  features,  it  would  be  a 
serious  (and  unfounded)  leap  of  logic  to  conclude  that  it  can  ensure  adequate  human 
performance  by  a  two-soldier  crew. 

The  CFM  analysis  via  IMPRINT  concentrates  wholly  on  combat  operations  in  the 
MGV  common  crew  station,  arguably  the  most  intense  and  cognitively  difficult  mission 
segment  of  the  MGV  fleet.  However,  the  IMPRINT  models  do  not  account  for  a  host  of 
other  functions  that  the  MGV  fleet  and  its  crew  members  will  take  on  outside  of  combat 
operations  that  can  be  very  demanding,  both  mentally  and  physically  (personal 
communication,  John  Lockett,  27  September  2005).  It  would  be  careless  not  to  point  out 
that  the  models,  in  their  present  state,  do  not  even  attempt  to  account  for  activities  such  as 
crew  rest  (sleep),  performance  under  fatigue,  environmental  taxons  such  as  heat,  cold, 
and/or  chemical-biological  warfare  environment.  The  models  do  not  account  for  physical 
labor  required  in  certain  resupply  and  logistics  operations,  where  an  extra  crew  member 
may  be  invaluable  in  loading,  unloading,  or  cross-loading  of  ammunition,  food,  water, 
and  other  supplies.  Lastly,  the  model,  running  only  60  minutes,  does  not  attempt  to 
understand  how  crews  would  perform  and  rest  under  long-tem  operations,  such  as  the  72- 
hour  mission  profile  dictated  in  the  FCS  O&O  Plan  and  ORD. 

C.  HSI  (MANPRINT)  DOMAINS  -  IMPLICATIONS  AND  TRADEOFFS 

The  proposed  human-automation  interface  scheme  for  the  MGV  fleet  can 
contribute  to  multiple  HSI  (MANPRINT)  domains  that  will  require  trade-off  analysis  to 
resolve.  We  can  anticipate  impacts  to  nearly  all  of  the  domains,  including  Manpower, 
Personnel,  Training,  Human  Factors  Engineering,  System  Safety,  and  Soldier 
Survivability  (see  US  DoDI  5000.2,  pp.  32-33,  and  US  Army  Regulation  602-2  for 
details  of  the  HSI/MANPRINT  domains  and  their  definitions). 
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1.  Manpower  and  Personnel 

The  trade-off  between  the  crew-size  requirements  in  the  ORD  and  overall  crew 
performance  was  the  prime  initiator  of  this  thesis.  Simply  writing  and  approving  a 
requirement  for  crew  of  set  size  is  not  enough.  The  crew-size  requirement  must  be 
balanced  with  requirements  in  human  factors  engineering  and  overall  human 
performance.  A  primary  conclusion  of  the  thesis  is  that  by  applying  the  proposed  human- 
automation  interface  model  to  other  functions  in  the  vehicles,  both  in  the  CFM  and  in 
vehicle-specific  function,  it  is  possible  to  make  further  reductions  in  operators  task¬ 
loading,  and  MWL.  This  will  also  support  attempts  to  achieve  the  current  ORD 
requirement  for  a  vehicle  operable  by  a  2-soldier  crew.  This  work  is  intended  to 
contribute  to  the  effort  to  ensure  that  vehicle  systems  in  the  MGV  fleet  can  accomplish 
the  overall  unit  mission  and  the  FCS’  mission  as  an  acquisition  program. 

However,  further  analysis  using  the  Target  Audience  Description  (TAD)  may 
reveal  that  not  just  any  soldier  will  be  able  to  man  a  vehicle  in  the  MGV  fleet.  It  may 
prove  much  more  difficult  for  a  brand  new  soldier  or  lower-category  soldier  to  efficiently 
and  effectively  operate  these  highly  advanced  crew  stations  across  the  MGV  fleet. 
Rather,  it  will  a  soldier  with  more  experience  or  more  intelligence  (i.e.  higher  test  scores) 
to  operate  in  the  crew  station  with  advanced  automation  schemes. 

An  additional  consideration  is  the  range  of  military  occupational  specialties 
(MOS;  see  US  Army  Pamphlet  611-21)  that  will  man  the  CCS  of  different  vehicles  in  the 
MGV  fleet.  Infantry  soldiers  will  be  in  the  ICV,  tankers  in  the  MCS,  medics  in  the  MV, 
artillery  soldiers  in  the  NLOS-Cannon,  various  logistics  and  maintenance  in  the  FRMV, 
etc.  Each  of  these  MOS  has  unique  requirements  for  physical  strength,  medical  status, 
and  intelligence/aptitude.  Yet,  they  will  all  be  manning  a  similar  CCS  that  may  not  take 
into  account  the  differing  personnel  requirements  of  all  the  MOS  called  to  man  the  crew 
station  in  the  O&O  plan. 
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2.  Training 

Regardless  of  final  design  of  the  human-automation  interaction  scheme  in  the 
MGV  fleet,  it  will  be  necessary  to  acquaint  soldiers  in  training  as  to  the  exact  nature  of 
the  resulting  interaction  between  themselves  as  operators  and  the  software/hardware 
automation.  The  extensive  literature  base  available  on  human-automation  performance 
makes  it  quite  clear  that  humans  and  failures  often  occur  when  the  operators  simply  do 
not  understand  what  the  automation  is  doing,  best  expressed  when  humans  start  asking: 
What  is  it  doing  now?  What  will  it  do  next?  Why  did  it  do  this?”  (see  Woods  &  Sarter, 
1998) 

As  with  the  possible  need  for  a  higher  category  of  soldier  to  man  the  MGV,  the 
requisite  amount  of  training  in  the  CCS  will  likely  increase.  This  is  especially  true  if 
high  levels  of  automation  are  introduced  in  some  functions.  The  soldier-operators  must 
be  able  to  clearly  understand  what  any  automation  scheme  is  doing  ‘behind  the  scenes’, 
so  to  speak.  They  must  have  a  succinct  and  accurate  ‘mental  model’  of  the  overall 
operation  so  that  they  are  able  to  anticipate,  troubleshoot,  and  even  take  over  from  the 
automated  system  when  necessary.  Simply  believing  that  certain  tasks  and  functions 
work  Tike  magic’  is  a  recipe  for  human  error  and  system  failure,  thus  a  degradation  in 
system  perfonnance. 

A  final  item  in  training  is  the  issue  of  soldier  trust  in  automation.  As  a  crewman 
and  part  of  this  total  vehicle  system,  the  soldier-operator’s  trust  in  the  automation  is 
dependent  on  his  familiarity  with  the  automation  scheme.  This  could  demand  longer 
training  periods  (in  or  out  of  the  schoolhouse)  and  high  fidelity  training  aids,  devices, 
simulators,  and  simulations  (TADSS).  There  are  also  accounts  of  operator  misuse  of 
automation,  where  excessive  trust  can  lead  operators  to  rely  uncritically  on  automation 
without  recognizing  its  limitations  or  fail  to  monitor  the  automation’s  behavior 
(Parasuraman  &  Riley,  1997;  see  also  Parasuraman  &  Miller,  2004;  Lee  &  See,  2004). 

The  increased  training  demands  may  be  alleviated  through  well-conceived, 
human-centric  embedded  training,  performance  support  systems,  and  job  perfonnance 
aids. 
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3.  Human  Factors  Engineering 

This  thesis  has  largely  been  a  human  factors  engineering  effort,  but  with 
definitive  effects  on  other  HSI/MANPRINT  domains.  The  proposed  qualitative  model 
has  a  goal  of  not  only  defining  the  human  role  in  the  overall  system,  but  also  in  keeping 
MWL  at  an  acceptable  level  during  the  entire  functional  flow.  It  fosters  improved  human 
performance  as  part  of  the  total  vehicle  system,  in  turn  enhancing  system  effectiveness 
and  suitability.  IMPRINT  is  a  good  way  to  quantify  the  effects  of  task-loading,  and  is  in 
extensive  use  already  in  the  MGV  program. 

4.  System  Safety  and  Soldier  Survivability 

The  potential  impacts  of  this  thesis  are  similar  for  the  System  Safety  and  Soldier 
Survivability  (SSv)  domains,  though  probably  less  effect.  System  safety  experts  normally 
conduct  extensive  Failure  Modes  Effects  Analysis  (FMEA)  and  Failure  Modes  Effect 
Criticality  Analysis  (FMECA)  concurrently  as  a  system  moves  from  Milestone  B  towards 
Milestone  C  in  the  DoD  systems  acquisition  process.  The  FMEA/FMECA  efforts  should 
be  widened  slightly  to  look  at  the  interaction  between  hardware/software  automation  and 
the  soldier-operators.  Ignoring  the  interaction  causes  the  FMEA/FMECA  efforts  to  miss 
possible  key  points  of  system  failure  that  may  not  be  attributable  directly  to  software, 
hardware,  or  human. 

The  impact  on  SSv,  similar  to  FMEA/FMECA,  lies  along  the  analysis  of  potential 
fratricide  as  a  result  of  a  breakdown  or  misinterpretation  of  the  human-automation 
interaction  scheme  in  the  vehicles.  Recommended  automation  levels  allow  sensors  and 
software  (automation)  to  be  much  more  involved  in  the  acquisition,  analysis  of  target 
information  than  in  the  past,  targets  that  may  be  friendly.  Likewise,  automation  in  the 
form  of  decision/action  support  may  err  and  recommend  action  against  a  friendly  target 
based  on  automated  target  assessment.  SSv  assessments  using  the  US  Army  Research 
Lab’s  PAL  (Parameter  Assessment  List)  should  include  checks  on  any  possible  fratricide 
potential  caused  by  unexpected  (or  incorrect)  human-automation  interaction. 
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D.  FURTHER  ACTIONS 

Parasuraman  et  al.  (2000)  proposed  both  primary  and  secondary  evaluative 
criteria  that  provide  a  good  road  map  of  further  actions  as  the  design  of  the  MGV  crew 
stations  continue.  In  the  primary  evaluative  criteria,  this  thesis  was  wholly  focused  on 
the  MWL  aspect,  analytically  predicting  task-loading  as  a  result  of  the  crew  station  and  it 
proposed  human-automation  interaction.  Once  simulations  and  prototypes  are  available 
for  user  demonstrations,  it  will  prove  useful  to  empirically  evaluate  mental  workload  via 
a  variety  of  means  (physiological,  primary  task,  secondary  tasks,  or  subjective  rankings; 
see  Gawron,  2000),  and  then  look  at  the  relationship  between  MWL  and  actual  crew 
performance. 

Parasuraman  et  al.  (2000)  emphasize  the  importance  of  testing  and  evaluating 
preliminary  choices  of  automation  functionality.  Iterative  testing  against  the  proposed 
primary  and  secondary  evaluative  criteria  will  establish  the  best  automation  levels  for  the 
system.  Complacency,  skill  degradation,  and  the  constructs  of  SA  can  be  evaluated 
throughout  the  development  testing  and  operational  testing  (DT/OT)  schedules. 
Additionally,  the  proposed  models  in  this  thesis  and  the  MGV  crew  stations  are  natural 
candidates  for  rapid  prototyping  and  experimentation  (see  Moore,  Kennedy,  and  Kem 
2003;  Kennedy  and  Durbin,  2005  for  examples).  Use  of  these  tools  and  techniques  during 
the  system  design  and  development  phase  of  the  DoD  acquisition  process  can  be  the 
primary  ways  to  gather  data  on  human  perfonnance  (primary  evaluative  criteria). 

Finally,  the  entire  FCS  program  is  decisively  moving  from  concept  to  reality. 
Further  iterations  of  the  systems  engineering  process  will  continue  to  further  define  and 
refine  necessary  the  details  of  the  MGV  crew  stations  and  the  exact  roles  for  soldiers  as 
the  operators  and  maintainers.  Human  factors  engineers,  manpower  and  personnel 
specialists,  training  designers,  and  safety,  health  and  survivability  analysts  will  be  needed 
to  round  out  a  design  team  with  other  engineers  of  various  backgrounds  (software, 
electronics,  mechanics,  etc.).  User  groups  and  SMEs  will  also  be  necessary  to  evaluate 
and  refine  the  design  as  the  system  takes  form. 
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VII.  CONCLUSIONS  AND  RECOMMENDATIONS 


This  thesis  provides  human  factors  engineers,  systems  engineers,  designers,  and 
developers  a  top-down,  overarching  approach  that  enables  them  to  explicitly  define  and 
design  the  interaction  between  proposed  automation  schemes  and  the  human  crew.  In 
effect,  it  constitutes  the  design  methodology  and  automation  philosophy,  as  espoused  by 
Rouse  et  al.  (1987).  A  qualitative  model  was  proposed  to  drive  the  functional  architecture 
and  human-automation  interface  scheme  on  the  Army’s  FCS  manned  vehicle  fleet.  The 
proposed  model  is  applied  to  a  portion  of  the  functional  flow  of  the  MGV  common  crew 
station  It  is  a  logical  approach  to  function  decomposition  with  a  reasonable  paradigm  to 
use  to  conceptualizing  the  shared  roles  between  human  and  automation.  With  this  tool  in 
hand,  the  exact  role  of  the  Soldier  operators  as  the  central  component  of  the  vehicle 
systems  can  be  more  clearly  understood  before  the  fielding  of  the  vehicle  systems.  The 
proposed  model  was  then  demonstrated  quantitatively  via  a  computational  task-network 
modeling  program  (IMPRINT),  to  gain  an  understanding  of  the  impacts  on  human  task¬ 
loading,  and  therefore  workload  and  human  performance. 

Judicious  application  of  the  proposed  qualitative  model,  coupled  with  quantitative 
analysis  of  the  task-loading  effects  via  IMPRINT,  can  be  continued  for  other  functions  in 
the  various  MGV  crew  stations.  This  will  further  provide  a  guide  to  defining  the 
relationship  between  human  and  automation  and  the  resulting  human  performance 
ramifications.  This  is  but  one  way  (among  several)  to  work  toward  the  ORD  requirement 
for  a  2-soldier  crew.  But,  even  if  the  2-soldier  crew  requirement  is  relaxed,  a  coherent 
plan  for  automation  will  help  to  ensure  soldier  performance  and  system  effectiveness. 
The  focus  of  the  model  is  to  ensure  that  a  reduced-crew  can  perform  well  enough  (not 
optimally)  to  accomplish  all  of  the  functions  and  tasks  asked  of  the  total  vehicle  system. 
If  we  eventually  conclude  that  an  additional  crewmember  is  required  on  the  various 
MGV  vehicles,  the  same  qualitative  and  quantitative  models  can  be  used  to  gain  a  clear 
understanding  of  the  human-automation  interaction  as  well  as  the  some  of  the  human 
performance  ramifications  in  terms  of  mental  workload. 
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While  this  thesis  focuses  on  ways  to  solve  real  technical  issues  in  the  FCS  MGV 
fleet,  the  model  and  analytical  processes  proposed,  or  similar  approaches,  certainly  are 
necessary  in  a  wide  array  of  complex  systems  in  multiple  domains  (aviation,  space, 
maritime,  ground  transportation,  manufacturing,  etc.).  As  a  thorough  literature  review 
reveals,  there  are  very  few  people  thinking  about  an  ‘automation  philosophy’  to  guide  the 
complex  interactions  between  humans  and  automation  to  ensure  total  system 
performance.  So  while  the  proposals  here  were  developed  for  the  FCS  MGV  fleet,  they 
are  in  no  way  limited  to  that  particular  application. 
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APPENDIX.  ADDITIONAL  EXAMPLE  OF  THE  MODEL  IN 
ACTION  -  US  NAVY’S  LITTORAL  COMBAT  SHIP 


Included  is  the  complete  paper  titled  Developing  a  Human-Automation  Interface 
Model  of  the  Littoral  Combat  Ship’s  Fire  Control  System.  It  was  published  in  the 
proceedings  of  the  2005  Human  Systems  Integration  Symposium  held  20-22  June  2005  in 
Arlington,  VA. 
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Joshua  S.  Kennedy,  Jeffrey  A.  Thomas,  and  John  M.  Green 


Developing  a  Human-Automation  Interface  Model 
of  the  Littoral  Combat  Ship’s  Fire  Control  System 


ABSTRACT 

This  paper  outlines  how  Human  Systems 
Integration  (HSI)  methodology  was  used  to 
design  a  fire  control  system  for  the  U.S.  Navy 
Littoral  Combat  Ship  (LCS)  as  an  example, 
with  an  emphasis  on  reductions  in  manning. 
The  design  team’s  original  objective  was  to 
design  a  control  system  for  the  main  gun  that 
could  be  operated  by  one  person  or  less. 
Mission  analysis  of  the  LCS  and  its  weapons 
systems  generated  possibilities  for  manning 
reduction  that  extend  well  beyond  the  ship’s 
main  gun.  The  team’s  application  of  HSI 
methodology  gave  rise  to  a  ‘fire  control 
system’  where  the  operator-automation  team 
could  accomplish  the  ship’s  surface  warfare  as 
well  as  air  self-defense  missions  with  only  one 
sailor.  The  team  applied  a  model  of  human 
interaction- with- automation  to  outline  the 
design  methodology  (Parasuraman,  Sheridan, 
&  Wickens,  2000).  This  approach  also 
delineates  several  tradeoffs  among  HSI 
domains  to  be  made  in  further  iterations  of  the 
HSI  process.  In  order  to  ensure  optimal  system 
performance,  it  is  critical  to  implement  HSI 
methodology  for  all  complex  systems 
requiring  a  human  interface. 

INTRODUCTION 

In  support  of  its  Sea  Power  21  strategic  vision, 
the  U.S.  Navy  is  developing  the  Littoral 
Combat  Ship  (LCS)  to  deliver  focused  mission 
capabilities  to  enable  joint  and  combined 
forces  the  capability  of  defeating  the 
conventional  and  asymmetric  access-denial 
threat  in  the  littoral  area  (U.S.  Navy  PEO 
Ships,  2004). 


defended  directly  from  the  sea.  The  LCS  will 
defeat  enemy  littoral  defenses  including 
mines,  fast  swarming  small  boats,  and 
submarines,  ultimately  ensuring  maritime 
access  in  any  enviromnent  (see  figure  1). 
“Working  together  as  part  of  a  netted 
distributed  force,  this  future  fleet  will  project 
power  forward  and  enable  naval  and  joint  task 
force  commanders  to  dominate  the  littoral 
battlespace”  (US  Navy,  2004). 


Figure  1  Artist  Conception  of  Littoral 
Battlespace 


Mission  Analysis 

This  project  was  a  course  requirement  for 
SI400 1  (Systems  Integration  and  Architecture) 
as  part  of  the  new  HSI  Masters  of  Applied 
Science  program  at  the  Naval  Postgraduate 
School  (NPS),  CA.  The  professor  is  the  third 
author.  In  the  beginning  of  the  course,  he 
issued  this  directive:  “Design  a  control  system 
for  the  LCS  guns  that  can  be  operated  by  one 
person  or  less”.  Our  team  understood  this  to 
be  a  primitive  need  statement  that  supports 
minimal  manning  and  provided  a  starting 
point  for  the  analysis  process. 


The  littoral  area  of  control  extends  from  the 
open  ocean,  to  the  shore,  and  to  those  inland 
areas  that  can  be  attacked,  supported  and 
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At  first  glance,  we  were  tempted  to  use  the 
traditional  approach  of  applying  only  human 
factors  engineering  design  concepts  to  design 


a  computer  display  for  the  LCS  gun  system. 
However,  since  it  is  closely  related  to  systems 
engineering  (SE),  the  HSI  process  must  begin 
with  a  thorough  understanding  of  the  U.S. 
Department  of  Defense  and  the  U.S.  Navy’s 
needed  capabilities  (requirements  analysis). 
Three  Navy  lieutenants  and  four  Army 
civilians  conducted  background  research  into 
the  LCS  and  various  gun  systems  to  identify 
capability  gaps  between  legacy  gun  systems 
and  the  intended  capabilities  of  the  LCS  gun 
system.  We  derived  an  accepted  gun  system 
designed  from  the  user’s  perspective  to  enable 
and  enhance  the  LCS  capabilities  in  the 
littoral. 

The  LCS  Flight  0  Interim  Requirements 
Document  (IRD)  was  the  primary  reference 
document  (US  Navy  2003).  The  LCS  focused 
mission  capabilities  are  mine  warfare  (MIW), 
littoral  surface  warfare  (SUW)  against  small, 
highly  armed  boats,  and  littoral  anti-submarine 
warfare  (ASW).  Its  inherent  mission 
capabilities  include  joint  littoral  mobility, 
maritime  interdiction/interception  operations, 
homeland  defense,  and  others.  In  addition,  to 
support  its  focused  and  inherent  mission  area, 
it  must  also  have  core  capabilities  for  air  self 
defense  (ASD),  survivability,  aviation  support, 
logistics,  and  others.  Based  on  the  IRD,  the 
gun  control  system  for  the  LCS  must  help 
enable  the  LCS  to  achieve  these  capabilities — 
and  do  it  with  one  operator  or  less. 

Going  from  a  “Gun  Control  System”  to 
a  “Fire  Control  System” 

Mission  analysis  of  the  LCS  and  its  weapons 
systems  generated  possibilities  for  manning 
reduction  that  extended  well  beyond  the  ship’s 
main  gun.  The  team’s  application  of  HSI 
methodology  gave  rise  to  a  ‘fire  control 
system’  where  the  operator-automation  team 
could  accomplish  the  ship’s  surface  warfare  as 
well  as  air  self-defense  missions  with  only  one 
sailor.  The  system  is  made  up  of  not  only  the 
hardware  and  software,  but  also  the  humans 
that  must  operate,  maintain,  and  support  it. 

The  human  element  of  the  system  will 


ultimately  affect  its  operational  effectiveness 
and  suitability. 

After  gaining  an  understanding  of  the  LCS 
missions  and  what  the  gun  control  system 
must  support,  we  began  to  ask  some  questions: 

Ql)  What  exactly  are  the  targets  of  the  gun 
system? 

Al)  The  naval  officers  on  the  team  said  it 
would  be  the  surface  threat  of  multiple  small 
boats. 

Q2)  Will  the  gun  system  ever  shoot  at  an 
aerial  threat,  like  a  threat  aircraft  or  an  anti¬ 
ship  cruise  missile  (ASCM)  as  per  the  ASD 
capability? 

A2)  No.  Other  systems  on  the  LCS  address  the 
aerial  threat.  For  example,  the  MK  1 5  Phalanx 
Close-In  Weapons  System  (CIWS)  can  be 
used  against  ASCM,  the  SM-2  Standard 
Missile  SM-2  can  be  used  against  threat 
aircraft,  and  the  RIM-7  Sea  Sparrow  missile 
against  either. 

Q3)  Will  the  CIWS,  SM-2,  or  RIM-7  ever  be 
used  against  surface  threats? 

A3)  No,  they  are  strictly  for  ASD. 

Q4)  What  does  the  gun  system  do  during 
MIW  and  ASW? 

A4)  Nothing,  there  are  other  weapons  systems 
used  for  those  missions. 

So  then  we  asked  ourselves  the  crucial 
question:  Can  we  have  one  operator  control 
the  weapons  for  both  SUW  and  ASD?  At  this 
point  in  the  process,  we  hatched  the  idea  to 
band  together  these  mission  capabilities  under 
a  single  operator.  Of  course,  this  concept  is 
easier  conceived  than  realized,  so  the  rest  of 
this  paper  portrays  our  application  of  HSI 
methodologies  while  working  on  this  idea. 

Consequently,  our  proposal  is  more  than  a  gun 
system — it  is  an  integration  of  the  SUW  and 
ASD  weapons  systems  into  a  fire  control 
system  (FCS)  that  can  be  run  by  one  sailor. 
This  FCS  will  integrate  the  gun  system  to 
support  the  SUW  focused  mission  capability, 
plus  any  combination  of  CIWS,  SM-2  and 
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RIM7  to  help  achieve  the  ASD  capability 
(both  ASCM  and  threat  aircraft.  Figure  2 
shows  a  graphic  representation  of  our 
proposal. 

The  mission  statement  of  this  fire  control 
system  will  be  to  enable  the  LCS  to  effectively 
deliver  primary  and  inherent  mission 
capabilities  in  the  littoral.  It  shall  be  operated 
by  one  person  or  less.  It  shall  integrate  and  use 
the  common  tactical  picture  (CTP)  to  detect, 
track,  engage,  and  destroy  targets.  Its  primary 
objective  will  be  to  conduct  SUW  and  ASD 
independently  or  as  part  of  a  carrier  strike 
group  (CSG)  or  expeditionary  strike  group 
(ESG). 


Figure  2.  Proposed  Fire  Control  System 


Assumptions 

To  begin  setting  up  a  functional  flow  for  the 
FCS  and  its  automation,  we  had  to  make 
several  assumptions.  First,  any  control  system 
on  the  LCS  will  be  based  on  the  threat  posture 
of  the  ship,  typically  determined  by  the  ship’s 
commanding  officer  or  higher  authority.  To 
begin  the  design,  we  designated  three  postures 
similar  to  (in  order  of  severity):  WHITE, 
YELLOW,  and  RED.  The  color  codes  are 
also  used  as  air  defense  warnings  by  the  U.S. 
Department  of  Defense  (DoD)  to  denote 
degree  of  air  raid  probability.  In  our  system, 
WHITE  means  attack  by  hostile  forces  is 
improbable,  YELLOW  means  attack  by 


hostile  forces  is  probable,  and  RED  means 
attack  by  hostile  forces  is  imminent  or  is  in 
progress.  This  threat  posture  will  determine 
the  level  of  FCS  automation  in  use,  and 
represents  the  first  time  a  human  interfaces 
with  the  overall  system. 

As  a  necessity  to  begin  the  functional  flow,  we 
also  assumed  high  trust,  due  to  reliable 
automation.  This  assumption  will  be 
rigorously  evaluated  during  its  life  cycle,  but 
further  design  is  very  difficult  without  it. 

Lastly,  we  assume  that  a  high  threat 
environment  equals  a  high  mental  workload 
environment.  If  there  are  multiple  surface  and 
aerial  targets  to  detect,  track,  identify,  and 
engage,  then  the  operator’s  mental  workload 
(MWL)  will  be  appreciably  higher.  The  ship 
will  likely  be  at  threat  posture  RED. 
Conversely,  a  low  threat  environment  equals  a 
low  mental  workload  environment  (i.e.  threat 
posture  WHITE). 

Functional  Flow 

As  shown  in  figure  3,  the  FCS  functional  flow 
has  six  major  functions  that  are  iteratively 
performed  for  each  new  contact: 

1 .  Search  for  contacts 

2.  Detect 

3.  Track 

4.  Classify 

5.  Resolve 

6.  Shoot 

Most  of  these  functions  are  self-explanatory, 
but  two  of  them  need  further  definition.  Step 
4,  Classify,  is  where  the  FCS  determines  if  the 
target  is  a  threat  or  not.  Since  the  FCS  is 
made  up  of  hardware,  software,  and  humans, 
this  function  may  be  carried  out  by  any 
combination  of  these  components,  depending 
on  the  automation  design.  Step  5,  Resolve,  has 
a  dual  meaning.  In  this  stage,  the  system 
seeks  to  gain  greater  resolution  on  the  target, 
acquiring  more  information  to  help  decide 
whether  to  attack  it  or  not.  This  stage  is  also 
about  resolving  to  destroy  or  not.  Classify  and 
Resolve  are  functions  where  the  system  will 
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have  to  make  multiple  decisions  prior  to 
carrying  out  an  action  (Step  6,  Shoot). 


Figure  3.  FCS  Functional  Flow  (Level  1) 


Figures  4  and  5  show  a  more  detailed 
functional  flow,  with  multiple  subfunctions 
under  the  six  primary  functions. 


Figure  4.  FCS  Functional  Flow  (Level 
2) 

HUMAN-IN-THE-LOOP 

We  have  mentioned  the  FCS’  automation 
several  times,  and  that  this  automation  must 
allow  one  operator  to  control  weapons  to 
support  both  the  SUW  and  ASD  missions. 
The  critical  question  to  be  answered  at  this 
point  is  where  and  how  the  operator  will 
interface  with  the  automation  in  the 
functional  flow  of  this  system? 


To  answer  this  question,  we  needed  an 
operator-in-the-loop  paradigm. 

We  found  such  a  paradigm  in  Parasuraman, 
Sheridan,  and  Wickens  (2000),  whose  model 
is  the  foundation  of  our  automation  design 
process.  Their  model,  for  types  and  levels  of 
automation,  provides  a  framework  for 
deciding  what  aspects  of  the  system  should 
be  automated  and  to  what  extent. 
Appropriate  selection  of  automation  levels  is 
important  because  “automation  does  not 
merely  supplant  but  changes  human  activity 
and  can  impose  new  coordination  demands 
on  the  human  operator”  (2000).  Automation 
can  vary  across  a  continuum  of  levels,  from 
the  lowest  level  of  fully  manual  control  to 
the  highest  level  of  full  automation.  Table  1 
shows  a  proposed  10-point  scale,  with 
higher  levels  representing  increased 
autonomy  of  computer  over  human  action 
(2000).  For  example,  at  a  low  level  2, 
several  options  are  provided  to  the  human, 
but  the  system  has  no  further  say  in  which 
decision  is  chosen.  At  level  6,  the  system 
automation  gives  the  human  only  a  limited 
time  to  override  before  carrying  out  the 
decision. 
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Figure  5.  FCS  Functional  Flow  (Level  2)  (continued) 


Table  1.  Levels  of  Automation  of 
Decision  and  Action  Selection 
(Parasuraman  et  al,  2000) 

HIGH  10.  The  computer  decides  everything,  acts 
autonomously,  ignoring  the  human 
9.  Informs  the  human  only  if  it,  the 
computer,  decides  to 
8.  Informs  the  human  only  if  asked 
7.  Executes  automatically,  then 
necessarily  informs  the  human 
6.  Allows  the  human  a  restricted  time  to 
veto  before  automatic  execution 
5.  Executes  the  suggestion  if  the  human 
approves 

4.  Suggests  one  alternative 
3.  Narrows  the  selection  down  to  a  few 
2.  The  computer  offers  a  complete  set  of 
decision/action  alternatives 
LOW  1.  The  computer  offers  no  assistance; 

human  must  take  all  decisions  and 
actions 


Information  Information  Decision  Action 

Acquisition  Analysis  Selection  Implementation 

Automation  Automation  Automation  Automation 

Level  Level  Level  Level 


High  High  High  High 


Figure  6.  Levels  of  Automation  for 
independent  functions  of  information 
acquisition,  information  analysis, 
decision  selection,  and  action 
implementation.  Examples  of  systems 
with  different  levels  of  automation 
across  functional  dimensions  are  also 
shown  (Pararsuraman  et  al,  2000) 


Using  their  model,  we  developed  an 
automation  scheme  for  the  FCS.  In  Figure  7, 
instead  of  presenting  system  alternatives  for 


Parasuraman  et  al  (2000)  proposed  that 
automation  can  be  applied  to  four  broad 
classes  of  functions  as  shown  in  Figure  6. 
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analysis,  we  propose  three  possible  levels  of 
automation  based  on  the  LCS’  threat  posture 
(RED,  YELLOW,  or  WHITE).  As  per  our 
main  assumption,  a  higher  threat  level 
(RED)  means  a  higher  level  of  human 
MWL,  so  we  propose  a  higher  level  of 
automation  across  the  four  broad  classes. 
Conversely,  a  low  threat  level  (WHITE) 
means  a  lower  level  of  MWL.  In  the  first 
two  stages  (Acquisition  and  Analysis),  there 
are  high  levels  of  automation  in  all  three 
postures.  The  human  operator  is  largely  a 
supervisor  in  the  Acquisition  stage, 
presented  with  information  only:  the  status 
of  SUW  and  ASD  weapons,  status  of 
various  LCS  sensors  (radar,  sonar,  etc.),  and 
status  of  the  common  tactical  picture  with 
other  ships,  vehicles,  and  aerial/space 
platforms,  among  other  options.  Likewise, 
in  the  Analysis  stage  the  automation 
presents  the  operator  information  about 
targets  detected,  including  characteristics  of 
the  target  (bearing,  speed,  altitude)  and  the 
symbology  assigned  by  the  FCS. 


Acquisition  /  Observe  Analysis  /  Orient  Decision  /  Decide  Action  /  Act 


High 


High 


High 


High 


•  Status  of  weapons 

•  Status  of  own  ship  sensors 
•Status  of  CTP/LINK 


•  Symbology  of  target 

•  Characteristics  of  target 
(e.g.  bearing,  speed,  altitude 


Figure  7.  First  stage  automation 
scheme  for  FCS, 


The  human  operator  takes  a  more  active  role 
between  the  Analysis  and  Decision  stages  as 
defined  by  the  ship’s  threat  posture,  which 
in  turn  defines  the  level  of  automation  in 
use.  In  the  WHITE  posture,  the  human 
might  have  more  authority  over  FCS 
decisions  to  be  made  and  total  control  over 


the  action  to  be  taken.  In  the  RED  posture 
(high  threat,  high  MWL),  the  automation 
might  have  more  autonomy  and  the  human 
would  presumably  only  have  authority  to 
override  the  action  the  FCS  is  about  to  take. 
The  YELLOW  posture  might  take  a  level  of 
automation  between  WHITE  and  RED. 

We  also  note  that  the  four  broad  functions  of 
Parasuraman  et  al.  are  analogous  to  the 
Observe-Orient-Decide-Act  (OODA)  loop 
commonly  used  by  DoD  personnel  across  all 
U.S.  military  Services. 

Next,  we  applied  our  functional  flow  to  the 
proposed  automation  scheme,  replacing  the 
four  broad  functions  with  the  six  major  FCS 
functions  (see  figure  8).  Search  replaces 
Acquisition;  Detect  and  Track  replaces 
Analysis;  Classify  and  Resolve  replaces 
Decision,  and  Shoot  replaces  Action.  Again, 
the  three  possible  levels  of  automation  are 
RED,  YELLOW,  and  WHITE.  For  the 
Search,  Detect,  and  Track  functions,  we 
reasoned  that  a  high  level  of  automation  is 
warranted.  The  FCS,  using  the  ship’s  sensor 
and  the  CTP,  will  search,  detect  and  track  all 
targets,  then  present  real-time  and  concise 
information  to  the  operator  about  those 
targets,  as  well  as  the  status  of  SUW  and 
ASD  weapons,  sensors,  and  common  tactical 
picture. 


Search  (.1) 

High 


Detect  (.2)  &  Track  (.3)  Classify  (.4)  &  Resolve  (.5)  Shoot  (.6) 

High  High  High 


1  Status  of  weapons 
1  Status  of  own  ship  sensors 
■Status of  CTP/LINK 


•  Symbology  of  target 

•  Characteristics  of  target 
(e.g.  bearing,  speed, 
altitude 


1.  What  is  classification?  Is 
THREAT? 

2.  What  to  shoot  at  first? 

3.  Which  weapon? 

4.  Shoot  or  not  shoot? 


Ship  heading 
Actuation  of 
weapon 


Figure  8.  Proposed  Automation 
Scheme  for  the  LCS  Fire  Control 
System 
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The  Classify  and  Resolve  functions 
(replacing  Decision)  is  present  four  major 
decisions  that  the  system  (both  software 
and/or  human  operator)  must  make. 

1 .  What  is  the  classification  of 

the  target?  Is  it  a  threat? 

2.  What  is  the  priority  target? 

What  should  the  FCS  shoot  at  first? 

3.  Which  weapon  to  use 

against  that  target? 

4.  Shoot  or  not  shoot? 

One  major  value  of  this  automation  proposal 
based  on  the  Parasuraman  et  al.  model  is 
that  system  designers  can  fine-tune  the 
levels  of  automation  at  each  of  the  vertical 
lines  in  the  diagram.  Y ou  can  simply 
modify  the  level  of  automation  as  you  might 
move  the  slider  bars  up  and  down  much  in 
the  same  way  of  slider  bars  on  a  stereo 
equalizer,  thereby  achieving  the  balance 
between  human  and  software  that  the  system 
designers  and  engineers  desire. 

In  the  WHITE  posture,  due  to  the  assumed 
low  threat  level  and  low  operator  MWL,  we 
propose  that  the  operator  interacts  more 
fully  with  the  software.  In  the  first  decision, 
the  FCS  automation  classifies  the  target  and 
makes  a  recommendation  to  the  operator, 
who  can  then  confirm  the  classification  or 
countermand  the  recommendation.  This 
would  be  similar  to  level  4  or  5  in  table  1 . 
Continuing  through  the  functional  flow,  the 
automation  may  then  present  a  single 
recommendation  for  the  highest  priority 
target  (level  3  or  4).  When  choosing  the 
appropriate  weapon  system,  automation 
level  rises  back  up  to  level  4/5  (makes 
recommendation,  then  executes  if  operator 
approves).  Since  the  optimal  weapon  to  use 
against  the  selected  target  is  entirely  a 
function  of  target  characteristics  (surface  vs. 
air,  then  ASCM  vs.  aircraft),  we  believe  the 
automation  would  make  a  better  and  faster 
decision  recommendation  than  the  human. 
The  final  decision,  to  shoot  or  not,  is  left 
entirely  to  the  human;  the  automation  offers 
no  assistance.  In  this  regard,  at  the  WHITE 
posture,  the  human  operator  will  be  under 


absolutely  no  pressure  or  suggestions  to  ‘pull 
the  trigger’ — he  will  be  able  to  make  that 
decision  unfettered  by  any  recommendations 
from  the  software.  Lastly,  the  actual  act  of 
actuating  the  chosen  weapon  is  left  entirely  to 
the  operator  (who  at  this  point  is  probably 
under  supervision  from  a  more  senior  officer) 
with  no  input  from  the  FCS  automation. 

In  the  YELLOW  posture,  in  response  to  the 
higher  threat  level,  we  can  simply  move  up 
the  slider  bars  on  selected  decisions  to  allow 
the  system  to  achieve  more  efficient 
performance  while  probably  allowing  an 
intermediate  level  of  operator  MWL. 
Decisions  1-3  might  remain  at  level  4/5,  but 
the  automation  will  be  allowed  greater 
autonomy  (and  thus  influence)  in  Decision  4 
by  actually  recommending  to  shoot  at  (or  not 
shoot  at)  the  target  with  the  selected  weapon 
system.  However,  as  with  the  WHITE 
posture,  the  final  action  is  left  entirely  to  the 
operator  (and  possibly  his  higher 
supervisors). 

In  the  RED  posture,  due  to  the  assumed  high 
threat  level  and  to  help  alleviate  the  likely 
high  MWL  of  the  operator,  we  propose  that 
the  software  maintain  a  higher  degree  of 
autonomy  throughout  the  Classify  and 
Resolve  functions,  probably  similar  to  level  7 
as  per  table  1  (software  decides 
automatically,  then  informs  the  human; 
human  can  step  and  override  the  automation). 
Unlike  the  other  two  threat  levels,  we 
propose  that  in  RED,  the  automation  has 
much  greater  autonomy,  being  allowed  to 
execute  the  action  unless  the  operator 
overrides  the  action.  This  kind  of  autonomy 
may  likely  well  be  warranted  in  high  threat 
environment  with  multiple  surface  and  air 
threats.  In  addition,  but  noted  in  figure  8,  is 
the  possibility  of  having  the  FCS  makes  a 
steering  recommendation  for  the  ship,  or 
even  steer  the  ship  itself  (though  this 
possibility  may  be  controversial).  This  kind 
of  design  decision  would  have  to  be  decided 
at  the  highest  levels  of  the  LCS  program 
leadership  with  input  from  users  and  subject 
matter  experts. 
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Decision 

Red 

Yellow 

White 

Threat? 

FCS  decides. 

Operator  must 
override 

FCS  recommends. 
Operator  confirms 

FCS  recommends. 
Operator  confirms 

Priority? 

FCS  decides, 

Operator  must 
override 

FCS  recommends  one 
target.  Operator 
confirms 

FCS  gives  range  of 
choices.  Operator 
decides 

Weapon? 

FCS  decides. 

Operator  must 
override 

FCS  recommends. 
Operator  confirms 

FCS  recommends. 
Operator  confirms 

Shoot? 

FCS  decides, 

Operator  must 
override 

FCS  recommends. 
Operator  confirms 

Operator  decides,  no 
input  from  FCS 

Action-Shoot 

FCS  shoots,  Operator 
must  override 

Operator  shoots 

Operator  shoots 

Table  2.  Operator- Automation 
Interaction  at  Key  Decision  Points 


Table  2  summarizes  the  proposed  levels  of 
automation  for  each  function  and  the  major 
decision  points.  Again,  these  levels  are 
proposals  based  on  team  discussions  with 
several  subject  matter  experts  (SMEs).  The 
value  of  the  Parasuraman  et  al.  model  is  that 
further  discussions  within  various  working 
groups  (WG)  and  integrated  products  teams 
(IPT),  based  on  experience  or  other 
empirical  research,  can  easily  fine-tune  the 
automation  levels  as  necessary.  Of  course, 
there  is  also  the  possibility  of  adding  or 
removing  functions  or  decisions  from  the 
functional  flow  and  subsequently  the 
automation  scheme  as  depicted  in  figure  8. 

In  figures  9-1 1,  we  present  the  latter  half  our 
FCS  functional  flow  (figure  5)  for  each  of 
the  three  threat  postures.  The  four  major 
decisions  in  the  Classify  and  Resolve 
functions  (denoted  by  stars)  have  generally 
increasing  levels  of  automation  as  threat 
posture  goes  from  WHITE,  YELLOW,  and 
then  RED  in  response  to  the  operational  and 
intelligence  situation.  The  former  half  of  the 
functional  flow  is  not  presented  since  we 
proposed  that  automation  levels  remain  the 
same  in  the  Search,  Detect,  and  Track 
functions  for  each  of  the  three  threat 
postures. 


Figure  9.  FCS  Functional  Flow  at 
threat  posture  WHITE.  The  four  key 
decisions  (stars)  and  the  action  are 
spotlighted. 

HSI  DOMAINS— 
IMPLICATIONS  AND 
TRADEOFFS 

The  proposed  FCS  and  its  automation  scheme 
has  major  impacts  on  multiple  HSI  domains, 
and  we  have  identified  a  number  of  tradeoffs 
that  need  resolving  should  the  system 
continue  design  and  development. 

Manpower,  Personnel,  and  Training 
(MPT) 

The  zero-based  manning  concept  drove  this 
design  from  the  beginning,  and  if  the  FCS 
concept  is  brought  to  fruition,  we  stand  to 
merge  manpower  from  three  or  four  different 
weapon  systems  into  one  fire  control  system 
operator 

In  addition,  though  not  discussed  in  this 
paper,  there  is  the  possibility  of  incorporating 
certain  electronic  warfare  (EW)  into  the 
automation  scheme  under  the  same  operator. 
Of  course,  all  this  assumes  well-designed  and 
reliable  automation. 

As  a  tradeoff  for  the  possible  manpower 
savings,  this  automation  scheme  will  require 
increased  development  cost  and  time  from 
systems  software  engineering.  Most 
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acquisition  officials  would  probably 
characterize  it  as  a  high-risk  effort  in  terms 
program  cost,  performance,  and  schedule. 


Figure  10.  FCS  Functional  Flow  at 
Threat  Posture  YELLOW.  Levels  of 
automation  of  slightly  higher  for 
Decisions  1-3 


Figure  11.  FCS  Functional  Flow  at 
Threat  Posture  RED.  Level  of 
Automation  higher  for  All  Decisions 
and  the  Action 

An  additional  tradeoff  will  be  in  the 
Personnel  domain,  as  the  knowledge,  skills 
and  abilities  needed  to  operate  this  system 
may  require  higher  aptitudes  than  current  or 
legacy  technology.  It  may  not  be  possible 
for  new  sailor  or  lower-category  sailor  to 
operate  this  system;  rather,  it  may  take  an 
experienced  and  intelligent  petty  officer  or 


junior  officer  to  operate  the  FCS  as  proposed. 

Likewise,  the  requisite  amount  of  training  to 
operate  this  proposed  FCS  will  increase.  As 
part  of  this  system,  the  operator’s  trust  in  the 
proposed  FCS  automation  is  highly 
dependent  upon  his  familiarity  with  the 
automation  scheme  driving  the  FCS.  This 
will  demand  longer  training  periods  and  high 
fidelity  training  aid,  devices,  simulators,  and 
simulations  (TADSS).  It  also  points  out  the 
probable  need,  based  on  training  needs 
analysis,  for  a  stand-along  TADSS  off-ship, 
as  well  as  onboard  scenarios  built  into  the 
FCS.  However,  the  increased  training 
demand  may  be  alleviated  through  well- 
conceived  embedded  training,  performance 
support  systems,  and  job  performance  aids. 

Human  Factors  Engineering 

We  have  an  implicit  goal  of  keeping  operator 
MWL  at  an  acceptable  level  during  the  entire 
functional  flow  across  all  possible  threat 
postures.  This  is  to  foster  improved  human 
performance  as  part  of  the  system,  in  turn 
improving  overall  system  effectiveness  and 
suitability.  HSI  practitioners  can  build  a 
comprehensive  workload  model  to  assess 
whether  MWL  is  kept  at  reasonable  levels 
throughout  the  functional  flow  at  different 
threat  levels.  For  example,  the  Improved 
Performance  Research  Integration  Tool 
(IMPRINT)  from  the  US  Army  Research  Lab 
(ARL)  is  a  well-documented  and  widely-used 
tool,  particularly  for  human  performance  in 
military  applications  (see  the  IMPRINT 
website  at:  http://www.arl.army.mil/  ARL- 
Directorates/HRED/ imb/ imprint/ 
Imprint7.htm. 

FURTHER  ACTIONS 

Evaluative  Criteria 

Automation  is  not  an  all-or-none  affair; 
rather,  it  can  vary  by  type.  In  the 
Parasuraman  et  al.  model,  and  as  used  by  our 
team,  human  interaction  with  automation  can 
be  applied  to  any  or  all  of  a  system’s 
functional  flow  at  the  level  required  to  gain 
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optimal  system  performance.  Parasuraman 
et  al.  (2000)  argue  that 

any  particular  level  of  automation 
should  be  evaluated  by  examining  its 
associated  human  performance 
consequences.  These  constitute  the 
primary  evaluative  criteria  for  levels  of 
automation.  However,  human 
performance  criteria  is  not  the  only 
important  factor.  Secondary  evaluative 
criteria  include  automation  reliability 
and  the  costs  of  decision/action 
consequences. 

Automation  can  have  both  beneficial  and 
negative  effects  on  human  performance. 
There  are  four  human  performance  areas 
that  should  be  included  in  the  primary 
evaluate  criteria  of  this  FCS:  mental 
workload,  situation  awareness, 
complacency,  and  skill  degradation  (2000). 
Evidence  suggests  that  well-designed 
information  automation  can  change  MWL  to 
a  level  that  is  appropriate  for  the  systems 
tasks  being  performed.  However,  “clumsy” 
automation  can  lead  to  increasing  workload. 
As  mentioned  above  in  the  HFE 
implications,  MWL  can  be  modeled  during 
system  design  to  assess  if  it  is  reasonable 
throughout  system  functional  flow. 

Besides  unbalanced  MWL,  automation  can 
incur  human  performance  costs  in  the  other 
three  criteria  suggested.  Situation  awareness 
can  be  negatively  affected  when  the 
operators  loses  “awareness  of  the  system 
and  certain  dynamic  features  of  the  work 
environment”  (2000).  If  the  FCS  automation 
is  highly  but  not  perfectly  reliable  in 
executing  the  major  decision  choices,  “then 
the  operators  may  not  monitor  the 
automation  and  its  information  sources  and 
hence  fail  to  detect  the  occasional  times 
when  then  automation  fails”  (2000)  or  is 
wrong.  Complacency  is  greatest  in  high 
MWL  setting  when  the  operator  is  engaged 
in  multiple  tasks.  Third,  skill  degradation 
can  certainly  occur  over  time  if  the  system 
decisions  are  routinely  carried  out  by  the 
automation.  “These  potential  costs — 


reduced  situation  awareness,  complacency, 
and  skill  degradation — collectively 
demonstrate  that  high-level  automation  can 
lead  to  operators  exhibiting  out-of-the-loop 
unfamiliarity.  All  three  sources  of 
vulnerability  may  pose  a  threat  to  safety  in 
the  system  failure”  (2000).  The  FCS 
automation  design  must  demonstrate  that 
potential  human  performance  costs,  along 
with  unbalanced  MWL,  do  not  occur.  “By 
considering  these  human  performance 
consequences,  the  relative  merits  of  a  specific 
level  of  automation  can  be  determined” 
(2000). 

Secondary  evaluative  criteria  can  include 
automation  reliability  and  the  cost  of  decision 
and  action  outcomes.  Reliability  is  typically 
defined  in  probabilistic  terms,  such  as  a 
reliability  of  .997  or  a  mean  time  to  failure  of 
10,000  hours.  In  addition,  “failures  may 
occur  not  because  of  a  predictable  (in  a 
statistical  sense)  malfunction  in  software  or 
hardware,  but  because  the  assumptions  that 
are  modeled  in  the  automation  by  the 
designer  are  not  met  in  a  given  operational 
situation”  (2000).  The  reliability  of 
automation  also  influences  human  trust, 
possibly  undermining  potential  system 
performance  benefits  when  the  automation  is 
underused  or  disabled.  In  addition  to 
reliability,  “assessing  the  appropriate  level  of 
automation  for  decisions  requires  additional 
consideration  of  the  costs  associated  with 
decision  and  action  outcomes”  (2000). 

Incorporating  Prior  Research,  Rapid 
Prototyping  and  Experimentation 

Our  decisions  on  the  type  and  level  of 
automation  throughout  our  functional  flow 
was  determined  by  team  discussions,  input 
from  locally  available  SMEs,  and  our  own 
reasoning,  all  with  the  goal  of  improved 
human  performance  in  the  resulting  system 
(primary  evaluative  criteria).  Additionally, 
there  is  the  possibility  of  incoiporating  prior 
research  into  these  decisions  on  the 
appropriate  type  and  level.  For  example,  prior 
research  may  have  shown  that  compared  to 
manual  operations,  both  human  and  system 
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performance  are  enhanced  by  level  4 
automation  but  degraded  by  automation 
above  level  6  (2000).  Based  on  this  research, 
we  apply  the  finding  at  the  appropriate  place 
in  the  framework.  In  lieu  of  prior  research, 
performance  modeling  may  provide  similar 
guidelines. 

Parasuraman  et  al.  (2000)  emphasize  the 
importance  of  testing  and  evaluating 
preliminary  choices  of  automation 
functionality.  Iterative  testing  against  the 
proposed  primary  and  secondary  evaluative 
criteria  will  establish  the  best  automation 
levels  for  the  system.  Additionally,  the 
proposed  FCS  and  it  automation  is  a  natural 
candidate  for  rapid  prototyping  and 
experimentation  (see  Moore,  Kennedy,  and 
Kern  2003;  Kennedy  and  Durbin,  2005  for 
examples).  Use  of  these  tools  and  techniques 
during  the  system  design  and  development 
phase  of  the  DoD  acquisition  process  can  be 
the  primary  ways  to  gather  data  on  human 
perfoimance  (primary  evaluative  criteria). 

Finally,  the  proposed  FCS  is  still  very  much 
a  concept.  Further  iterations  of  the  SE 
process  will  be  required  to  further  define 
and  refine  necessary  capabilities  and 
operational  requirements  as  part  of  the  LCS. 
Human  factors  engineers  and  MPT 
specialists  will  be  needed  to  round  out  a 
design  team  with  other  engineers  of  various 
backgrounds  (software,  electronics,  etc.). 
User  groups  and  SMEs  will  also  be 
necessary  to  evaluated  and  refine  the  design 
as  the  system  takes  shape. 

CONCLUSION 

The  LCS  is  designed  to  fight  and  win  the 
world’s  littoral  area,  but  it  must  do  so  with 
significantly  less  manning  than  historically 
used  on  our  ships.  The  zero-based  manning 
concept  and  the  constraint  of  a  single 
operator  likely  requires  the  increased  use  of 
automation.  Automation  design  is  both  art 
and  science,  and  can  be  guided  by  the  model 
presented  by  Parasuraman  et  al.  Given  the 


primitive  need,  our  team  judiciously  applied 
and  modified  the  model  in  order  to  design  an 
FCS  with  an  automation  scheme  that  allows 
one  operator  to  control  the  weapons  systems 
for  both  the  SUW  and  ASD  mission  of  the 
LCS.  Judicious  application  of  the 
Parasuraman  et  al.  model  in  other  programs 
may  help  achieve  reduced  manning  without 
sacrificing  human  and  system  performance. 
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